Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add expected assertion count #626

mgol opened this issue Jul 17, 2014 · 9 comments

Add expected assertion count #626

mgol opened this issue Jul 17, 2014 · 9 comments


Copy link

mgol commented Jul 17, 2014

Especially with async tests it's very useful to be able to check if assertion count at the end of the spec matches what was actually checked. This would also allow to catch mistakes like:


(which I've experienced yesterday).
An API could look like:

it('a test', function () {
  // error: two assertions expected

or like that:

it('a test', function (2[, done]) {
  // error: two assertions expected
Copy link

infews commented Aug 27, 2014

Are you seeing false positives in your project?

Knowing how many expectations are in a spec feels like a testing smell. The project would have to update the count and the expectations every time a given spec changed.

Thanks for the feature request. However, given that we've not heard about this request before, it would require more work in every single spec, and it would require more work of all users, I'm going to close this issue.

If you still feel strongly about this, let's have a discussion about this on the Jasmine list. We can reconsider if the community thinks the core team is off base.

@infews infews closed this as completed Aug 27, 2014
Copy link

I would love this feature, it exists in js-test-driver. It's really useful for asynchronous test cases to make sure all your callbacks are called.

it('should check my variable after a timeout', function() {
     var val = true;
     }, 0);

The above test should fail but ends up passing because I forgot to define the done parameter. This bug just bit me on a project, so I googled for that feature

It's worth mentioning that in the example above, you'd get an error on your console because done is not defined. However, in my case, my callback was never being called because my widget under test was destroyed in afterEach() so no callbacks were ever callled so it was truly a false positive

Copy link

Ciantic commented Mar 25, 2016

It need not to be asynchronous test to be difficult to refactor so that expect is at the end of the function.

I'm testing react components, and I have expect inside the render, e.g.

    it("should duplicate state to props of the component", function () {
        interface IProps {
            prop1? : string;
            prop2? : string;
        class Component extends React.Component<IProps, void> {
            static actions;
            static defaultActions = {};
            static defaultProps: IProps = {
                prop1: "1",
                prop2: "2"

            render() {
                    prop1: "connected 1",
                    prop2: "connected 2"

                return (

        interface IState {
            connectedComponent?: {
                prop1?: string;
                prop2?: string;
        let simpleRedux = new SimpleRedux<IState>({
            connectedComponent : {
                prop1: "connected 1",
                prop2: "connected 2"

        let ComponentConnected = simpleRedux.connector(Component)(
            s => (s.connectedComponent),
            (p => {
                throw Error("This must not be run");
            }) as any

        const component: React.Component<{}, {}> = TestUtils.renderIntoDocument(
            <Provider store={}>
                <ComponentConnected />

I can't neatly move it outside the render, the component given by React TestUtils is utter garbage.

Edit I did refactor it finally to right format, but in async cases it is not always viable.

Copy link

@mgol @infews Can anybody confirm if there was any advancements in this matter? Is there any links to a list where we can see the discussion mentioned in the comment above? I ask this because this issue is the first result in Google when looking for "jasmine expected assertion count".

This is such a basic feature to prevent false positives when working with asynchronous functions or just a couple of mocks (to ensure tests refactor do not lose determinism in the future). QUnit has it and works like a charm, but unfortunately it doesn't have the same fluency as the jasmine style of writing tests.

Copy link

Ciantic commented Apr 7, 2016

@FagnerMartinsBrack I would not expect this to be fixed, same problem with Chai: chaijs/chai#94 and it have been there for years.

Copy link

Jasmine will now tell reporters the number of expectations that were made in each spec. The HTMLReporter will report to your console any specs that don't make any expectations at all. We don't want to require all specs to have expectations, as there can be reasons you may want a spec like that.

At this point, I think this is probably how it will be for the foreseeable future.

Copy link

hmdhk commented Jun 23, 2017

@slackersoft , I think there's no need for jasmine to require all specs to have expectations, simply by providing the number of expect calls the developer can choose to fail tests if there are no expectations.

Is the number of expectations accessible during the test?

Copy link

UziTech commented Jul 31, 2017

I created an plugin that will do this called jasmine-expect-count


it("should call expect 3 times", function () {


  const p = new Promise(function (resolve) {
    setTimeout(function () {
    }, 1);


  // if returning p is forgotten only 2 expects will be called.
  return p;

Copy link

iwllyu commented Sep 12, 2017

jest has this implemented

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

9 participants