In software engineering, unit testing is crucial to the functionality, maintainability, and reliability of the code base.\nBy isolating the smallest testable unit (a function, class, etc.) and abstracting away its dependencies, it is possible to validate the robustness and accuracy of each unit.<\/p>\n
In order to focus on the unit under test itself, we must often mock its dependencies.\nThis way we can simplify our tests and force our unit under test to flow through different logical branches of the code – all without relying on any external systems or potentially changing implementations.<\/p>\n
Jest<\/a> is one of the most common testing frameworks for testing JavaScript Code.\nTS-Jest<\/a> provides seamless integration between TypeScript (TS) and Jest, making it simple to write tests in TS.\nNot only does Jest now integrate with TS, it also has fully fledged mocking functionality that allows us to write high quality unit tests.<\/p>\n In this blog post, we walk through samples of how to utilize mocking in different unit testing scenarios. The code for these samples can also be found in this GitHub repository<\/a>.<\/p>\n Very often, the class under test depends on instances of other classes.\nTypically, in following the dependency inversion principle<\/a>, individual classes should depend on interfaces — the implementation of which are often passed in through the class’s constructor.\nThis gives us much flexibility in testing, allowing us to simply define the mocks that implement the required interfaces and pass them through the constructor of a class when writing its unit tests.<\/p>\n Let’s use the following Since this The underlying Now, at the beginning of each test, we can create an We should also clear the mocks after (or before) each test is run to make sure there is no carryover of information or state between tests.\nThis is a best practice that should be kept in mind when working with mocks in Jest.<\/p>\n Moreover, with all the mocks in place, we now can write tests for the Note: To check out the full code\/test sample, see the repo<\/a><\/p><\/blockquote>\n Like with other dependencies in unit testing, we mock static functions so that we can focus on testing the unit’s logic in isolation.\nThis ensures that the testing process is reliable and efficient.\nMocking static functions also allows us to control the behavior and responses of the static function during testing, so we can create deterministic tests that have predictable outcomes.<\/p>\n One common scenario where we may need to mock a static function is when following the Factory Design Pattern<\/a> to create a new object as follows:<\/p>\n In this case, we want to mock our static Let’s take an example, which is detailed further in this section of the repo<\/a>:<\/p>\n Say, we want to test a method that gets a new Person object from a Then we can use the Finally, we can call our function under test and expect the returned message to be a simple hello to our mocked Person.<\/p>\n Note: To check out the full code\/test sample, see the repo<\/a><\/p><\/blockquote>\n Environment variables are very useful in software engineering for many reasons including application configuration.\nMany classes require these configurations to determine their behavior.\nWhile there is a preference for reading these environment variables in at the app entry point and passing config objects to classes (making testing very simple), there are times when this may not be possible.\nIn this other case, where you must access the environment variables directly (using If your tests are simple and every test file can use the same exact set of environment variables, utilize the However, in most cases, where different environment variables or the flexibility to change environment variables on a per test basis is needed, follow the sample scenario described below:<\/p>\n For this scenario, we have a simple (but admittedly useless) We must unit test to see whether the Because these tests will change environment variables, we first cache the old environment in the Note: if the entire test file requires the same set of environment variables, you can set them in the Note: To check out the full code\/test sample, see the repo<\/a><\/p><\/blockquote>\n Sometimes there are instances where you cannot constructor inject a dependency and you rely on constructing a dependency in your code itself.\nWhile this makes testing more difficult, Jest has a workaround.\nThis section shows how to mock classes from npm packages that are constructed in code.\nBy using the As an example, let’s assume we have an HTTP-triggered Typescript Azure Function that deletes entities from Azure Table Storage.\nBecause TypeScript Azure Functions doesn’t come with a Dependency Injection framework out of the box, in our basic Azure Function we construct a In order to mock this class (as well as the We can also make assertions on how many times the Note: To check out the full code\/test sample, see the repo<\/a><\/p><\/blockquote>\n Overall, utilizing Jest’s mocking features can make unit testing TypeScript applications easy.\nIn this blog post, we have detailed a few common scenarios that we have come across in our team’s work, but this is certainly not an exhaustive list.\nRefer to the Jest Mocking Documentation<\/a> for additional information on mocking with Jest.<\/p>\nMocking Instances of Classes<\/h2>\n
Introducer<\/code> class (from this section of the repo<\/a>) as an example:<\/p>\nexport class Introducer {\r\n constructor(private personClient: IPersonClient) {\r\n }\r\n\r\n helloPerson(id: string): string {\r\n return `Hello ${this.personClient.getName(id)}!`;\r\n }\r\n\r\n askAQuestion(id: string): string {\r\n const age = this.personClient.getAge(id);\r\n const name = this.personClient.getName(id);\r\n return age > 22 ? `What do you do for a living ${name}?` : `What's your favorite hobby ${name}?`;\r\n }\r\n}<\/code><\/pre>\nIntroducer<\/code> class depends on an IPersonClient<\/code> instance and because we don’t want to use the real Person API<\/code> in our unit tests, we create a mockPersonClient<\/code>.<\/p>\nconst mockPersonClient = {\r\n getName: mockGetName,\r\n getAge: mockGetAge\r\n};<\/code><\/pre>\nIPersonClient<\/code> methods are mocked outside of the mockPersonClient<\/code> object so that additional assertions can be made around the context of these functions (how many times they were called and with what arguments).\nThis is done via the mockImplementation<\/code> method<\/a> available on the Jest mock created with the jest.fn()<\/code> function<\/a>:<\/p>\nconst mockGetName = jest.fn().mockImplementation((id): string => {\r\n return people[id].name;\r\n});\r\nconst mockGetAge = jest.fn().mockImplementation((id): number => {\r\n return people[id].age;\r\n});<\/code><\/pre>\nexpect(mockGetName).toBeCalledTimes(1);\r\nexpect(mockGetAge).toBeCalledTimes(1);<\/code><\/pre>\nIntroducer<\/code> instance with our mock IPersonClient<\/code>:<\/p>\nconst introducer = new Introducer(mockPersonClient);<\/code><\/pre>\nafterEach(()=> {\r\n jest.clearAllMocks();\r\n})<\/code><\/pre>\nIntroducer<\/code> public methods.\nThe full tests can be found in this test file<\/a><\/p>\nMocking Static Functions<\/h2>\n
export class PersonFactory {\r\n private static _instance: IPerson;\r\n\r\n static getInstance(name: string, age: number): IPerson {\r\n if (!PersonFactory._instance) {\r\n const persona = new Person(name, age);\r\n PersonFactory._instance = persona;\r\n }\r\n\r\n return PersonFactory._instance;\r\n }\r\n}<\/code><\/pre>\ngetInstance<\/code> function within our Factory class.\nWe use the jest.spyon()<\/code><\/a> function and the .mockReturnValue()<\/code> method to overwrite our original Factory method and return a mocked object.<\/p>\ngetInstance<\/code> method in a PersonFactory and then returns a message that says hello to that person.\nTo test this function, as our unit under test, we must first mock our returned person object.<\/p>\nconst mockAnnika = {\r\n nickname: 'Annika',\r\n age: 22\r\n};<\/code><\/pre>\njest.spyon()<\/code> function on the PersonFactory so that the class’s getInstance<\/code> method will be overwritten to return our mocked person object.<\/p>\njest.spyOn(PersonFactory, 'getInstance').mockReturnValue(mockAnnika);<\/code><\/pre>\nconst returnedHelloAnnika = HelloPerson.sayHelloAnnika();\r\nexpect(helloAnnika).toEqual(\"Hello, \" + `${mockAnnika.nickname}!`);<\/code><\/pre>\nMocking with Environment Variables<\/h2>\n
process.env.YOUR_ENVIRONMENT_VAR<\/code>), there are a few things to consider during testing.<\/p>\nsetupFiles<\/code><\/a> field of the jest.config.js<\/code> to point to a TS file that will be run before each test file is executed (where you can set your environment variables) as shown here<\/a>.<\/p>\nLoggingService<\/code> that returns different strings based on which environment it is in (Azure vs Local):<\/p>\nexport class LoggingService {\r\n constructor() {\r\n }\r\n\r\n \/\/ returns a string just for example sake\r\n info(message: string): string {\r\n const loggingEnvironment = process.env.LOGGING_ENVIRONMENT;\r\n\r\n if (loggingEnvironment == \"AZURE\") {\r\n return \"[AZURE] \" + message;\r\n } else {\r\n return \"[LOCAL] \" + message;\r\n }\r\n }\r\n}<\/code><\/pre>\nLoggingService<\/code> returns the right string based on the environment variables set.<\/p>\nbeforeAll<\/code> block and reset this exact environment after all the tests in the afterAll<\/code> block.\nBefore each test, we importantly utilize the jest.resetModules()<\/code><\/a> function so that modules are imported again in between each test.\nThis is especially important if the class being tested captures environment variables globally (in its file but outside the class definition).\nLastly, because the LoggingService<\/code> code and what we’re testing is so basic, at the beginning of each test, we simply set the required environment variable and test the output of the info(message: string)<\/code> function based on that environment variable:<\/p>\nprocess.env.LOGGING_ENVIRONMENT = \"AZURE\";\r\nconst message = \"message\";\r\nexpect(loggingService.info(message)).toBe(\"[AZURE] \" + message);<\/code><\/pre>\nbeforeAll<\/code> via process.env.______<\/code> or add them to a test.env<\/code> file and load them using a library like dotenv<\/a>:<\/p><\/blockquote>\nbeforeAll(() => {\r\n \/\/ cache a copy of user env before tests\r\n cachedEnv = { ...process.env };\r\n \/\/ add 'test.env' values to user env\r\n dotenv.config({ override: true, path: path.resolve(__dirname, 'test.env') });\r\n});\r\n\r\nbeforeEach(() => {\r\n \/\/ Resets the module registry - the cache of all required modules.\r\n \/\/ This is useful to isolate modules where local state might conflict between tests.\r\n jest.resetModules();\r\n\r\n \/\/ Create logging service for tests\r\n loggingService = new LoggingService();\r\n})\r\n\r\nafterAll(() => {\r\n \/\/ reset user env vars\r\n process.env = cachedEnv;\r\n});<\/code><\/pre>\ntest.env<\/code>:<\/p>\nLOGGING_ENVIRONMENT=LOCAL<\/code><\/pre>\nMocking NPM Libraries<\/h2>\n
jest.mock()<\/code> method, we can specify the library to mock and add the list of dependencies desired, including the classes that need to be constructed.<\/p>\nTableClient<\/code> inline:<\/p>\nconst httpTrigger: AzureFunction = async function (context: Context, req: HttpRequest): Promise<void> {\r\n ...\r\n const tableClient = new TableClient(\r\n config.STORAGE_ENDPOINT,\r\n config.STORAGE_TABLE_NAME,\r\n new AzureNamedKeyCredential(config.STORAGE_ACCOUNT_NAME, config.STORAGE_ACCOUNT_KEY),\r\n );\r\n try {\r\n await tableClient.deleteEntity(entityName, rowKey);\r\n ...\r\n } catch {\r\n ...\r\n }\r\n ...\r\n};<\/code><\/pre>\nAzureNamedKeyCredential<\/code> required in its constructor) from the @azure\/data-tables<\/code> library, we set up the mock of TableClient<\/code>\nand AzureNamedKeyCredential<\/code> at the top of the test file:<\/p>\nconst mockedDeleteEntity = jest.fn();\r\n\r\njest.mock('@azure\/data-tables', () => ({\r\n \/\/ use \"function\" syntax since they need to be instantiated\r\n AzureNamedKeyCredential: function () {\r\n return 'test credential';\r\n },\r\n TableClient: function () {\r\n return {\r\n deleteEntity: mockedDeleteEntity,\r\n };\r\n },\r\n}));<\/code><\/pre>\ndeleteEntity<\/code> function is called on the TableClient<\/code> by making its implementation a Jest function (jest.fn()<\/code>):<\/p>\nexpect(mockedDeleteEntity).toBeCalled();<\/code><\/pre>\nConclusion<\/h2>\n