In Jest there are functions like tobeCalled or toBeCalledWith to check if a particular function is called.
Is there any way to check that a function is not called?
Just use not.
expect(mockFn).not.toHaveBeenCalled()
See the jest documentation
not did not work for me, throwing a Invalid Chai property: toHaveBeenCalled
But using toHaveBeenCalledTimes with zero does the trick:
expect(mock).toHaveBeenCalledTimes(0)
Recent versions of Jest (22.x and onwards) collect quite decent statistics of mock functions calls, just check out their docs.
The calls property shows you the number of calls, the arguments passed to the mock, the result returned out of it and whatnot. You can access it directly, as a property of mock (e.g. in a way how #Christian Bonzelet suggested in his answer):
// The function was called exactly once
expect(someMockFunction.mock.calls.length).toBe(1);
// The first arg of the first call to the function was 'first arg'
expect(someMockFunction.mock.calls[0][0]).toBe('first arg');
// The second arg of the first call to the function was 'second arg'
expect(someMockFunction.mock.calls[0][1]).toBe('second arg');
I personally prefer this way as it gives you more flexibility and keeps code cleaner in case if you test for different inputs that produce a different number of calls.
However, you can also use shorthand aliases for Jest's expect since recently (spy matchers aliases PR). I guess .toHaveBeenCalledTimes would suit fine here:
test('drinkEach drinks each drink', () => {
const drink = jest.fn();
drinkEach(drink, ['lemon', 'octopus']);
expect(drink).toHaveBeenCalledTimes(2); // or check for 0 if needed
});
In rare cases, you might even want to consider writing your own fixture that'd do the counting. It could be useful if you're heavy on conditioning or working with state, for example.
Hope this helps!
Please follow the documentation from jest:
https://jestjs.io/docs/en/mock-functions#mock-property
All mock functions have this special .mock property, which is where data about how the function has been called and what the function returned is kept. The .mock property also tracks the value of this for each call, so it is possible to inspect this as well: [...]
These mock members are very useful in tests to assert how these functions get called, instantiated, or what they returned:
// The function was called exactly once
expect(someMockFunction.mock.calls.length).toBe(1);
Or...
// The function was not called
expect(someMockFunction.mock.calls.length).toBe(0);
Related
It seems that, when I use thenReturn like this:
when(abc.call()).thenReturn(a).thenReturn(b),
I expect:
verify(abc, times(2)).call()
instead, the method seems only get called once, I am a little confused(my test work as expected, the mock seems return the value I expected), but for the invocation times, I don't know if I am getting the wrong result, or it's a expected behavior of the Mockito?
when() is mocking the abc.call() method which has to produce a certain return type. If the method is called once, it will return the value also once, so the stubbing for method invocation is done only once hence the verify only recognizes one call.
You need to customize your function so that the stub(abc.call()) gets called more than once.
You can follow this thread for implementing multiple stubs
Is there a way i can find out during runtime if a module is mocked via jest?
Since mocked modules get required normally and therefore the code gets executed (as seen here: jest module executed even when mocked
We need this because we have checks on top of each file to fail early when a mandatory environment variable is not set, which causes our tests to fail even if the module is mocked.
if (!process.env.SOME_ENV) {
throw new Error(`Mandatory environment variable 'SOME_ENV' not set`)
}
We are looking for something like this:
if (!process.env.SOME_ENV && utils.isNotMocked(this)) {
throw new Error(`Mandatory environment variable 'SOME_ENV' not set`)
}
where utils.isNotMocked(this) is the magic function which checks if the module is currently mocked.
As #jonrsharpe mentioned, it is typically not desirable that software can distinguish whether it is under test or not. This means, you will probably not find the feature you are hoping for in any mocking framework. Moreover, there may be more fundamental problems to provide such a feature, because you might have mixed test scenarios where for some test cases an object of the mocked class is used, and for other test cases an object of the original class is used.
Since you are using the early exit mechanism as a general pattern in your code, as you describe: What about creating a library function for this check - which then again can be doubled during testing such that in that case the function does not throw?
I'm reading the mocking capability of minitest.
require "minitest/autorun"
mock = MiniTest::Mock.new
mock.expect(:use_any_string, true, [String])
mock.use_any_string("foo")
## mock.use_any_string(1)
## MockExpectationError: mocked method :use_any_string called with unexpected arguments [1]
## I do not understand the purpose for this
mock.verify
So I do not understand the purpose of using mock.verify since the trying to pass any another type(to use_any_string) other than String result in mock expectation error.
So why should one use assert mock.verify then?
You are right, you cannot set anything else to the configured mock, but if your mock is not called at all, then you can find out with mock.verify. So if your method under test should call the mocked method, you should verify that it was called at all.
You are correct, mock.expect(:use_any_string, true, [String]) will cause the test to fail if the expected call is not made on the mock.
However using mock.verify depends on how you compose your test. In your example you are explicitly calling the method you are testing with mock.use_any_string("foo") so there is no need to also call mock.verify.
You could get into a scenario where you are not making this call explicitly, or are expecting the mock to have had calls made at a certain time. These scenarios would take advantage of mock.verify calls.
(Another note, minitest has recently introduced assert_mock which can be used instead of mock.verify)
I just started investigation of Sinon.JS and after some research I stuck with the following two methods and do not know how exactly they are working:
sinon.fake.yields(callback[, value1, ..., valueN]);
and
sinon.fake.yieldsAsync(callback[, value1, ..., valueN]);
It would be great if somebody explain (or even show some example) how they work and when should I use them. One more important question what is the difference between fake, stub and mock in common?
Thanks in advance!
The Sinon docs explain that yields() returns a fake that "expects the last argument to be a callback and will invoke it with the given arguments".
yieldsAsync() does the same thing but invokes the callback asynchronously.
Looking at the Sinon source code makes it clear exactly what this means:
Calling sinon.fake.yields(...) records the arguments passed and returns a function.
When the returned function is invoked it ignores all of its own arguments except the last one which it assumes is a callback. It then invokes that callback with the arguments it recorded from when it was created with yields():
import * as sinon from 'sinon';
const fake = sinon.fake.yields('arguments', 'passed', 'to', 'yields');
const callback = (...args) => {
console.log(args);
}
// logs the following to the console:
// [ 'arguments', 'passed', 'to', 'yields' ]
fake('every argument', 'except the last', 'is ignored', callback);
yieldsAsync() does exactly the same thing except that it invokes the callback asynchronously.
In Sinon, a spy "is a function that records arguments, return value, the value of this and exception thrown (if any) for all its calls". It just spies on the calls made to it. It can either wrap nothing or it can wrap and transparently pass through to an existing function.
A stub is a spy "with pre-programmed behavior". A stub lets you spy on the calls made to it and also lets you define how the function should behave (return value, exception thrown, etc.). If an existing function is wrapped in a stub the behavior defined by the stub is used instead of the function.
"fake was introduced with Sinon with v5. It simplifies and merges concepts from spies and stubs." It spies on the calls made to it like both spies and stubs, it can be created with or without behavior and it can also wrap an existing function.
A mock is a fake method "with pre-programmed behavior...as well as pre-programmed expectations". A mock lets you define how the function should behave and also how it is expected to be used. Calling verify() on a mock will fail if the mock was not used as expected.
I am trying to create a Node module (using harmony) that upon loading by another module/application, has to be yielded to so that things in it's construct can be executed and loaded before any of it's exposed functions can be called.
The issue I am having is that I cannot seem to yield to the internal function that is being executed, using module.exports. An example would help.
module.exports = function*(s_id){
console.log('loading the module lets it execute up till here');
if (!(this instanceof Tester)) return yield new Tester();
}
function* Tester(){
console.log('but we never execute this generator function');
}
Tester.prototype = {
model : function*(){
// other functions
}
}
It's been stumping me for hours now! I feel like the solution is super simple but I cannot seem to wrap my head around it. I have tried to simply make the Tester() function the export, but am still having the same issue. Why can't I seem to yield to the Tester() function?
Also, what may an alternative be to this approach? I want to maintain the Object nature of the module so that the module can be loaded with different inputs, such as the s_id variable/object in the example above.
a Node module (using harmony) that upon loading by another module/application, has to be yielded to so that things in it's construct can be executed and loaded before any of it's exposed functions can be called
Don't do that. Generators are not made for asynchrony. yield doesn't do what you want here. A module is not "yielded" to await something in it to load. yield is magic, but not async magic.
If you must use an asynchronous module loading process, export a promise for your actual module. That is a standard interface for something to await, and can be consumed using a standardized approach that does not rely on internals of your module.
You still can use yield syntax for constructing that promise, just use your favorite coroutine library.
return yield new Tester();
…
function* Tester(){…}
Uh oh. Well yes, apparently it is possible to call generator functions as constructors. But believe me, it is not what you want. A constructor for an arbitrary object should return that object, instead of an iterator (just like it shouldn't return a promise). If some of your object methods are generator methods, that's fine, but your constructor should be not.
If you really want to use a generator function in your code like that (and it's not meant to be a constructor), you
will need to yield* the iterator you've created (tester()) instead of yielding it
must not overwrite its .prototype property like you did, as that causes the iterator to malfunction. (Of course you should never do that at all, even though most of the time it works)