I was basically wandering around on Youtube looking for some videos on Unit Testing to help me with my current project and I stumbled across this video. I've seen some of Roy's other presentations, and I really think this is one of his best ones yet. Most of Roy's books are on .NET so it was nice to see him talking about Javascript. For your reference, here's teh video:
Key Takeaways
- In order work unit testing to work for your project, you must focus on these three things:
- Trustworthiness
- Maintainability
- Readability
- Roy describes unit tests as the "green zone" in that you should never, ever have unit tests that down pass when pulling down the project files and running the tests.
- It's interesting that he say's you shouldn't test private methods. He says that the public methods are the contract and that testing them should be enough. He mentions that sometimes if you really that you should be testing a private method then you probably ought to have it be public.
- He goes on to point out how many js frameworks don't have all their tests passing when you pull the project, and he really hates when there are failing unit tests, and he especially hates when there are failing unit tests and then some says, "don't worry about it because X" since that destroys the trustworthiness of your whole test suite.
- He emphasizes the "no broken windows" principle as it applies to unit tests- if you begin with bad practices or allow others to write tests with bad practices then others will copy them and it will turn into some of the awful examples that he shows in his slides.
- He makes a very clear distinction between unit tests and integration tests, and he mentions many times that he has two distinct "projects"; one for unit tests and one for integration tests. In Angular world these integration tests would be protractor tests, and the best practices for protractor and Jasmine tests match up with that Roy is saying about his integration tests.
My Recommended Angular 1 Unit & E2E Workflow
In terms of project structure, it would be interesting to know what Roy thinks about mine. I use the Gulp-Angular yeoman generator, and I really like their style. Basically, the e2e tests have their own seperate folder on the same level as your src folder, gulp folder, dist folder, etc. Then all of your source code, html, js, scss, images, fonts, sounds, etc, go inside of the src folder. Your unit tests (anything with a spec.js files) are automatically picked up by the trusty gulp scripts. I have a very component-focused directory structure, and I like to throw the unit tests right into the component folder with all the other source files. This helps me 1) to be able to find the tests easily, 2) to actually write a test- create a describe full of it's and fill it with useful test for that component, and 3) to always have a test that "goes with" a js file. What do I mean by this? For my file naming conventions I do all lowercase dashes separating words in the name, then a dot, and finally a suffix that corresponds to that type of Angular 1 component it is. So for example, I might create files called prize-generator.service.js or left-menu.controller.js, and I would be sure to create a prize-generator.service.spec.js and left-menu.controller.spec.js file. I really like having them in the each same folder, sitting directly next to each other, holding hands, laughing, having fun together. This way you can easily move back and forth, it makes sense since they are only using things in each other's classes. If you did not make a file for each js file, you are either not writing tests at all or putting some in the same file, in which case you'd want to refactor that out at some point anyway for separation of concerns. These are run on the command line with gulp test. My protractor tests, even though I don't 100% "like it", have a parallel source structure in the e2e folder I was talking about. These are also .spec.js files, but gulp knows they are protractor tests because they are in the e2e folder. They can also have .po.js files, interact with DOM by calling click events and keyboard inputs, and make real requests to your async calls.
If you have a testing directory structure that works for you or have comments on Roy's presentation, let me know in the comments. :)
RSS Feed