Entry and exit points
Get the project source code below, and follow along with the lesson material.
Download Project Source CodeTo set up the project on your local machine, please follow the directions provided in the README.md file. If you run into any issues with running the project source code, then feel free to reach out to the author in the course's Discord channel.
This lesson preview is part of the Pain Free Mocking with Jest course and can be unlocked immediately with a \newline Pro subscription or a single-time purchase. Already have access to this course? Log in here.
Get unlimited access to Pain Free Mocking with Jest, plus 70+ \newline books, guides and courses with the \newline Pro subscription.
[00:00 - 00:19] In this lesson, we will explore the importance of identifying the entry and exit points in the unit of work and how to test them effectively. In unit testing, a unit of work can be a single function or a module.
[00:20 - 00:30] Regardless of its size, every unit of work has an entry point that can be triggered from the outside. And it always ends up doing something useful.
[00:31 - 00:42] If a unit of work doesn't do anything useful, it's better to remove it from our codebase. When testing a unit of work, there are several aspects to consider.
[00:43 - 00:53] Firstly, we test for the return type. This means we verify that the unit of work returns the expected type of value, such as the data structure.
[00:54 - 01:11] Secondly, if the unit of work all has the state of the system, we need to test for state mutation. This involves checking whether the unit of work modifies the relevant variables , objects or data structures in the expected way.
[01:12 - 01:30] Lastly, if the unit of work calls a third-party dependency, we need to test for a quality data function, and the arguments used. This ensures that the unit of work interacts correctly with external components and passes the appropriate arguments to them.
[01:31 - 01:41] Let's look at some examples to better understand these testing aspects. Suppose we have a function that calculates the sum of two numbers.
[01:42 - 01:52] In this case, the return type will be the sum of the two numbers. We can write a test to verify that the function returns the expected result.
[01:53 - 02:05] Next, let's consider a function that increments a counter variable. Here, we need to test for state mutation by checking if the counter variable has been incremented correctly.
[02:06 - 02:21] The same goes for a system under unit that interacts with the database. We also need to check the database for data mutation. Finally, imagine a function that sends an email using a third-party library.
[02:22 - 02:39] In this case, we need to test that the function calls the appropriate third- party function and passes the correct argument. To summarize, when unit testing, it's crucial to identify the entry and exit point of the unit of work.
[02:40 - 02:57] We test for the return type, state mutation if applicable, and also ensure that any interactions with third-party libraries are correctly tested. By thoroughly testing these aspects, we can have confidence that our unit of work are functioning as expected.