Let’s say I need to write a test for the front end, in the following BDD style:
A user visits buysomething.com,
saves something to their wishlist,
and a saved item count is updated.
The result of the test is that DOM gets manipulated.
In my heart I feel this is better suited as an integration test – but my team is currently using jasmine to load fixtures and test such interactions. This can lead to brittle tests as they are reliant on a static fixtures instead of the actual markup.
Are we misusing Jasmine here?
1
Do both. Integration tests serve the purpose of checking that two pieces of functionality that should work together do work together. BDD (or any other form of acceptance) tests verify that the user-visible feature works according to the needs of the customer and the business. If the end requirement is that someone can access a website, you must do that with a non-integration test because that’s how the user will interact with the system.
All that being said, don’t get hung up on terminology. Call the tests whatever you want. At the end of the day the software needs to be tested. You don’t get bonus points for testing them with BDD or with functional or unit tests. The only bonus points are whether or not the software is as bug-free as possible.
In a perfect world you would have a huge pile of unit tests that test each unit individually, a smaller set of integration tests that verify the integration of each of those units, and an even smaller set that verifies that the UI is functioning properly and calls the appropriate functions. And, of course, an even smaller set of exploratory tests that let your trained quality analysts use their intuition to find the really deep, gnarly bugs that are hard to catch in an automated fashion.
1