28
loading...
Testing Stubbed Functionality in Code
One of the first things I do when writing Unit Tests is to stub out
console.debug and console.log. I do this on the off chance that I leave one in the code. This way, there aren't extraneous console's showing in the terminal when the tests are run.Don't get me wrong. I do not do this to be lazy. I take good care of my code and generally do not leave
console.log all over the place. I use this code to keep things clean in the display, pure and simple.Pure and simple that is until I realized that I had a new case for a slightly improved form of my stubbed-code.
Here is the original code in the
helper.ts file ...beforeAll(() => {
spyOn(console, 'debug').and.stub();
spyOn(console, 'log').and.stub();
});As you can see there is nothing more done here than stubbing out the two console options.
In
karma.conf.js, this is included ...module.exports = function (config) {
config.set({
...
files: [
'src/app/shared/_spec-tools/helper.js'
],
...
});
};I mentioned in the title, handling console while testing and the code below is a simple endpoint for code I intend to write as this function gets fully fleshed out (it's a stub, conceptually ... not a Unit Test sub). I am generating the visuals that will eventually be used, but there is no backend to connect to at this point in time.
I am using
console.log in this case to ensure I understand the values passed in and available that I intend to use some time in the future.handleFunctionality = (note: string): void => {
console.log(note, this.state);
};At the same time ...
console.log every time tests are run.So, here's the code that ensures the stubs are in place AND calls are reset after each test is run.
let consoleDebug;
let consoleLog;
beforeAll(() => {
consoleDebug = spyOn(console, 'debug');
consoleDebug.and.stub();
consoleLog = spyOn(console, 'log');
consoleLog.and.stub();
});
afterEach(() => {
consoleDebug.calls.reset();
consoleLog.calls.reset();
});console.log when my Unit Tests run.28