Add expected assertion count #626

Closed
mgol opened this Issue Jul 17, 2014 · 6 comments

Projects

None yet

6 participants

@mgol

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:

expect(some-long-expression);

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

it('a test', function () {
  this.expect(2);
  expect(true).toBe(true);
  // error: two assertions expected
});

or like that:

it('a test', function (2[, done]) {
  expect(true).toBe(true);
  // error: two assertions expected
});
@infews

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 Aug 27, 2014
@juanmendes

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;
     setTimeout(function(){
        expect(val).toBe(false);
        done();
     }, 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

@Ciantic

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() {
                expect(Object(this.props)).toEqual({
                    prop1: "connected 1",
                    prop2: "connected 2"
                });

                return (
                    <div></div>
                );
            }
        }

        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={simpleRedux.store}>
                <ComponentConnected />
            </Provider>
        );
    });

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.

@FagnerMartinsBrack

@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.

@Ciantic

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

@slackersoft
Jasmine member

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.

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