Key Takeaways
- 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.