00:00 Sometimes the fixtures you create may need an extra preparation step for them to work like this create mock file fixture Which whole purpose is to allow me to create temporary files with given content and file name during my tests To do that as the first thing it prepares this temporary directory on disk as a preparation step

00:18 then it exposes me the actual function that will write the file contents of the specified path and Finally it will remove the whole temporary directory as a part of the cleanup step And it's great that it can rely on this fixture life cycle to make sure that this preparation and cleanup phases happen at the right Time so when I'm using this fixture in test, for example here

00:37 We just will automatically spawn the right logic to prepare the temporary directory Create this temporary file and give me the file path So I'm able to test on it and once this test is done and this fixture is no longer needed It will run the cleanup phase automatically for me. But what happens in this case? It doesn't reference this fixture

00:56 So paying the price for spawning this temporary directory only to delete it immediately would be quite inefficient To solve this problem V test initializes your fixtures lazily So unless you actually reference this fixture from the test context V test will not run it at all

01:12 This is a really great default, but it comes with a catch. Let me show you I have another test fixture That's called create mock database in essence It allows me to spawn a mock SQLite database and pre-populated with particular tables and rows in those tables And then I have a test here for querying the user

01:29 I have a single test case that says that it should return undefined if the user by the given ID is not found So I run my query user function provided the user ID and expect that it resolves with undefined but if I try running this test, I Will see an error and the error will say that the table user doesn't exist

01:48 This error happens because my test case never referenced this create mock database utility So effectively it runs without any database mock at all this is a good use case to opt out from that lazy fixtures and have a Consistent default the safety net this fallback that no matter whether you reference in this fixture or not

02:06 You will always have the default mock behavior This is useful in mocking database connections or intercepting HTTP requests and tests You never want those things to happen for real while testing and this is where you come in Follow the instructions to configure this fixture to always be applied in tests Regardless if it's referenced or not

02:24 And once you do that go to the query user test suite and finish it You will have to complete two main use cases one that will use the mock database You will have to pre-populate some user rows Don't worry There will be some hints how to do that and also another use case where you would rely on the default mock state Give it your best and see you in a minute