I have heard more than often that we shouldn’t devote any time in unit testing (or test automation) in early stages of a startup. But I held an opposite view and I think it does matter and helps in long term. IMO, it saves a lot of time for tech team in general.
Can anyone care to share some learnings related to this or any interesting experiences?
I’m trying to push test driven development in our process but facing a lot of resistance
The objective of the unit test is to provide confidence to allow engineers to move fast. Initially, the codebases are simpler, and
What to build can change frequently. You may want to unit test parts of code which are prone to a lot of changes or fragile in nature. Generally, the early-stage startup users have a higher tolerance for bugs/issues, so you have some leeway there. Dimensions to think on
- Cost of mistake
- Clarity on what you want to build
- Repeat Nature of bugs
I believe that focus on quality is important - unit tests are just one aspect of it. Quality is a function of many variables but some of the below areas can help early-stage startups:
- Good code review and CI processes integrated into the dev workflows
- Seed data for testing
- Test framework for API tests
- Automated test cases for critical or complex APIs.
- Relevant and useful comments in the codebase and READMEs in the repo or wiki.
- Unit testing framework should be in place. Critical aspects of code should mandate unit tests (identified during PR reviews)
It is also important to make a distinction between:
- business logic
- network module
- UI Views
Usually, it is easier to unit test your network module and business logic. Unit testing UI Views involve incremental effort. Based on my experience covering the business logic and network module will get you covered for good and also not trade-off on velocity.
This topic was automatically closed after 180 days. New replies are no longer allowed.