Loading
Current section: Globals 5 exercises
solution

Environment variables

Loading solution

Transcript

00:00 To test this logging functionality reliably, I need to gain control over two things. The first one is this environment variable, and the second is the console log function, so I'm able to know how and when it's being called during the test run. So let's do just that. I will let the test set up, calling before all hook, and in that hook, I will introduce the spy

00:19 over the console log method. I will provide console as the target and log as the method name, and I will mock the implementation for console.log so it doesn't print anything during the test run. Next, I will add an after each hook, and in that hook, first, I will reset all mocks.

00:36 I will call v.resetAllMocks, and this will clear any records to the console log calls between the tests. And the second thing that I'm gonna do, I will call v.unstubAllEnvironments. This is a cleanup step for the mocks that we will introduce over process.environment later in each individual test.

00:55 And finally, I have the after all cleanup hook to restore all mocks. So this will revert the console log mock to its original unpatched implementation. There's already one test suite written here for basic emitting and adding listeners, so I'm gonna head to the next one. So in this one, I want to test that the emitter class

01:14 is actually printing something to the console when the node environment is development. So first, I need to force that environment variable to be development. I will call v.stubEnvironment, and this method accepts the variable name, node environment, and the value, development. So what this is gonna do, it will do basically process environment,

01:33 node environment, equal development. This is what VTEST is gonna do behind the scenes. So I will do this one, and now I'm able to call my emitter as I normally would, so I'm gonna add a listener. I will introduce a listener as a mock function, and event is gonna be hello. Oh, I already have a listener, nice.

01:51 And I will expect the console log, which is our mock function, to have been called with adding event listener for hello. Let me look up the right message here, so adding listener for hello event, so for hello event. Here we go. Then I'm gonna emit this hello event

02:11 with some data using john, john, and my next assertion is gonna be that I'm gonna assert on the message that I'm emitting listeners for the hello event. That includes number of listeners based on the same message that we have right here. So this is a very basic test for the case

02:32 when we do have to emit those events and have logs associated with them. But what about the production environment? Well, I have another test for production, so I'm gonna call v.stub environment, and here I will use production as the value of the node environment variable. And for the rest of it, the test will be pretty much the same. I'm gonna emit the event.

02:52 Then I'm gonna make sure that the console log method is not called at all because that's the entire purpose, to emit those login when running production. Then I'm gonna check the same assertion, but this time for the emit of events, so hello with the data of john. And finally, I will also make sure that console log has not been called.

03:12 Now I will run the tests with npm test to make sure that all of them are passing. So let's recap here. In order to gain control over process.environments, basically environment variables, I'm using v.stub environment method. I provide the environment variable

03:30 and the value I want it to have. To make sure that these calls don't conflict and persist between tests, I'm adding the after each hook and calling v.unstub all environment. And for the rest of it, I'm combining it with the spy on the console.log method, so I'm able to assert when the emitter class calls console.log.