Testing Software

Writing unit tests for code is surprisingly a hot button topic within software development. Many developers have very strong opinions in how tests should be approached, written, and implemented.

Over the past few months, several of our engineering departments have been pushing for more adoption of frontend tests for their code. Thanks to this push, our Frontend Platforms team has found that we need to put a lot more effort into the documentation around writing tests. Several engineers, from both our team and other feature teams, have been writing docs, pairing with others to write tests, and writing guides and presentations around unit testing.

Through all this work, we have slowly shifted our mindset from approaching testing as something that is a consistent, unit-based, solid foundation for an application to something that is a bit more fluid, a bit farther away from testing each unit individually, and something that changes as the application changes.

The key takeaway I have learned from a coworker is that the type and value of the tests you write depends on if you are writing the code for the application at the same time as the test or if you write the test after the feature is code-complete.

Writing tests before a code-complete feature is completely different from writing them when the feature is done

We have found that a lot of the pain points around writing unit tests are a result of attempting to write unit tests after the feature is code complete and deployed to production.

A lot of our other learnings have been so simply summarized by this tweet by Guillermo Rauch: