Entry and exit points
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.