Interested in some opnion…
I'm introducing unit testing of JS into a team, it'll largely be testing modules with many dom interactions and updates.
Traditionally I've always used mocks and spys when testing libraries such as jquery, but as this is a team new to unit tests I thought fixtures may help them to get up and running quicker.
Some concerns I have around the use of fixtures are:
- Tests could become more like integration tests – which we already have
- Lose the benefit of better written, strcutured, abstracted code that unit testing encourages.
- Fixtures will slow speed of the tests
- Maintenance of fixtures could become a hidden overhead.
But really interested to hear others opinion.
Thanks in advance
Best Answer
Indeed, such fixtures are not a good way to run unit tests. The goal of unit tests is to test a very specific (and often very small) part of the code in isolation from the remaining code and the environment. By making those tests rely on the particular state of the web page, you lose the “unit” aspect of your tests, meaning that you'll rather have system and integration tests instead.
You're also right about the speed aspect of the tests. DOM is known for being terribly slow, so if your tests rely heavily on DOM, don't expect to run thousands of them in a second.
You're equally right that maintenance of fixtures may be a difficult task. In essence, if the HTML structure of your web application changes, you have to reflect that in possibly every fixture. If fixtures are written by hand, you'll waste a lot of time doing that. If fixtures are generated, you may end up wasting a lot of time tuning the generator itself.
The benefit of your approach becomes noticeable when the choice is between testing at least something, or not testing anything at all. If the project is under time pressure, fixtures may be a good choice to introduce your team to automated testing.
If the project is small enough, such tests may be the only thing you need: adding unit testing won't bring too much in long term and will impact the project in short term.
If the project is large but there is no time to develop a full suite of unit tests, start by system testing with fixtures. Once you have enough branch coverage, you may focus on new code, code with the least coverage and code with the most bugs to add unit tests, class by class.
An important benefit is that if your code base is not well designed for unit tests, adding them now will require refactoring, which, in turn, may generate regressions. If you already have enough system tests using fixtures, your team may be more comfortable doing refactoring when adding unit tests later, knowing that they have system tests to detect at least some regressions.