Unit Testing Inertia

Getting over the inertia in not testing your already existing applications.

Transcript

1. Unit Testing Inertia Justin Yost Web Developer at Loadsys —twitter.com/jtyost2 —github.com/jtyost2 —yostivanich.com
2. Testing A New Application Is "Easy" —Clean slates are easy to test —Dependencies are limited to just whatever you created —Code can be written with the understanding of tests —There is no preconceived notion of how "fast" development occurs
3. Testing An Existing Application Is "Hard" —Lots of files/classes/methods —Maybe it's decoupled, probably it isn't —It's hard to form new habits —Worried about the speed of development
4. How Do You Balance Testing —There is no perfect solution —Your case will be different from mine —I can give some pointers though
5. Test What's Easy To Test —What is probably easy to test? —Stuff at the edges of your mental model for the app —In MVC architecture this is probably mostly the Model layer
6. Work Your Way Inward —Essentially pick the classes that are most decoupled from your app —Then work into the more coupled classes
7. Make A Plan For Writing Tests Along With Features —Every new method gets tests, prevent the problem from getting worse —Every new method created, another method gets tested —Every new class created, another class gets tested —Make it part of the budget for a new feature, add a few hours to test something else
8. Same Goes For Every Bug Fix —Fix a bug, write a test for it and something else
9. Follow Through —Get better at writing tests —Learn what needs to be tested and what doesn't —Learn from the bugs that happen "How could tests have caught this?"
10. Have Time Dedicated To Write Tests On The Big Stuff —Sometimes parts of the application just didn't envision tests —Sometimes you'll have forgotten what the code should do —Sometimes you'll have to just rewrite/refactor something
11. All Of This Is A Hypothetical Biggest barrier to writing tests on existing apps for us has been getting developers to writing tests
12. So Make Testing Mandatory (if you have to) —Unit Tests fail it doesn't go out —Require coverage % to increase with every PR —Do code reviews if you aren't
13. Wrap It Up —Test easy stuff, moving to hard stuff —Test 2 things for every 1 new thing written —Make tests part of the process
14. Questions?