Testing

Before I talk about testing, recently, I switched "from" email address of this newsletter. If Google gives a warning that it doesn't look safe, please mark it "Looks safe". If you want to unsubscribe you can do so at the bottom of the page.

And about testing, be a freak when it comes to that. It will save lives and cats. Test a lot. Did it happen that you opened a PR, someone reviewed it and left simple, straightforward feedback. You did the trivial change, pushed, and got approved but that small change caused a bug. Whether that bug was caught by QA, on staging, or in production, it should not have happened. You lose credibility if you do this.

First, try to cover your code with automated tests. Automated tests will give you confidence that what you are doing works and it will be easier to test some edge cases with automated tests instead of testing the workflow manually. It saves time especially when the code base gets bigger.

If you are a solo developer trying to make an MVP to get an idea validated, I wouldn’t recommend writing unit tests. While as a small-time app that is in beta you can get away without low-level tests. If needed write some e2e tests that make sure that critical workflows are functioning. Run them before release.

However, if the team has a handful of engineers and your application is out of beta, write low-level tests too. By low-level tests, I mean low-level than E2E tests. I am not a fan of unit tests that need a lot of mocking. A lot of unit tests are fragile, need a lot of mocking, and are not the best use of the developer’s time. If a piece of code can function like an independent unit then write tests for it. Writing tests will also surface issues with code. Good code is easier to test. If it’s not easier to test, rethink how you can write the code so it’s independently testable.

Use visual testing tools for UI and catching those pesky CSS errors.

If you are in a company where no one write tests and you feel they should. Start writing. Open PRs with complete tests. If they don’t even have a test suite, set up one. Create a PR and open it for review. Find some time to make improvements in the code base you work on. Your energy, work, and quality you produce can be contagious and attract more people into doing their best work.

Try to write tests as a user would use your application. Test your app/code as a black box. It’s a difficult balance to know how many low-level tests to write and when. This will come with experience. Try to write tests in a way that if you do some refactors in that code, the tests shouldn’t need changing. Structure code in a way that it’s independently testable as a unit.

Before you mark your PR ready for review, always test it manually as well. It is not the QA’s job. QA’s job is to assure quality. Not to test your code. It is the developer’s job to test their code and make sure it’s functional. I can not stress this enough. Test normal flows, test edge cases, and failure scenarios.

This is the last post of the series around the software engineering profession. From now on, I will post about the topic but not exclusively that. Posts will include other topics including indie hacking, life, and software. I will post less often though. If you don't want to listen to that, you can unsubscribe now.