I'm always being pushed for feature development and then held to dates that don't give enough time for writing unit tests.
What practices can I use to be a better advocate for getting unit tests written?
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this communityI'm always being pushed for feature development and then held to dates that don't give enough time for writing unit tests.
What practices can I use to be a better advocate for getting unit tests written?
Measure test coverage and make that coverage a visible KPI
Talk about testing in details during backlog refinement for the each ticket
Push for tests running in CI and require them to pass in order to merge code
Don't give immediate time estimates. Promise them tomorrow. Wait to be asked again.
Know and Use the 7 magic words for backlog refinement. How Are We Going To Test This ?
If forced to give an estimate triple the development time to allow for also writing the unit tests
Present topics such as the Agile Test Pyramid and How To Mock Our Data to the local community
Make plans for unit, integrated and e2e tests that the feature should include during backlog refinement
Make sure the product owner understand that application code requires unit tests as part of feature delivery
Don't give out updates in stand-ups that indicate that the feature is "done" or "mostly done" when the tests aren't done
What practices can I use to be a better advocate for getting unit tests written?
TDD.
The tests are the drivers of the production code production. By definition, you will always have the tests that represent the specific version of your product.
And it tends to yield better internal and external quality in the product.
Writing tests after the fact are mostly a waste of time.
They won't influence the design of your interfaces (which tend to be of lower quality);
The tests coding is an additional step after you already have the production code that brings value to the users;
The tests have the potential to be discarded on the next set of changes. Thus, they won't bring even regression detection benefits in this case.
There are some partially good answers here, but I think that in summary the answer is simple- Data. Show bugs that could have been avoided, estimate the needed time for testing and show the ROI on it, bring research showing the benefits in testing and demonstrate how simple adding tests can be.
Make unit testing part of your development process like in TDD. Unit tests speed up your productivity because when you change/refactor code you don't need to test many things manually or deploy the whole app. That's, I assume, something you, as a developer, know. But it might happen that your manager is less technical and hence doesn't know. And doesn't have to. And, controversially, you don't have to tell him.
I like what Martin Fowler wrote about refactoring:
Of course, many managers and customer don’t have the technical awareness to know how code base health impacts productivity. In these cases I give my more controversial advice: Don’t tell!
Subversive? I don't think so. Software developers are professionals. Our job is to build effective software as rapidly as we can. … A schedule-driven manager wants me to do things the fastest way I can; how I do it is my business. The fastest way is to refactor; therefore I refactor.
(Refactoring, 2nd Edition, p. 55)
I think the same applies to unit testing. Just replace "refactoring" with "unit testing" in the quote above.
As a developer, it's essential to prioritize testing along with feature development to ensure high-quality software. Here are some practices that you can use to advocate for getting unit tests written and get enough time for testing:
Educate stakeholders: Many stakeholders may not understand the importance of unit testing and the impact it can have on the quality of the product. It's essential to educate them about the benefits of unit testing and how it can save time and effort in the long run.
Estimate accurately: When estimating the time required for feature development, include time for writing unit tests and testing the code. Accurate estimation can help in setting realistic timelines and avoiding delays due to insufficient testing.
Prioritize testing: Prioritize testing as a critical part of the development process. Ensure that the development team understands that testing is as important as feature development, and the two should go hand in hand.
Automate testing: Automation can help in saving time and effort in testing. Automated unit tests can be executed quickly and can help in identifying issues early in the development cycle.
Use code review: Code review can help in identifying issues early in the development cycle. Code review can help in identifying code that is difficult to test and can help in improving the quality of the code.
Agile methodology: Agile methodology promotes testing as a continuous process throughout the development cycle. Agile development practices can help in delivering high-quality software on time.
Use Testing Metrics: Testing metrics can help in providing insights into the effectiveness of the testing process. Metrics can help in identifying bottlenecks in the testing process and can help in improving the overall testing process.
By adopting these practices, you can advocate for getting unit tests written and ensure that you get enough time for testing. Remember, testing is an integral part of the development process, and the two should go hand in hand.
Edit: Answering Rsf's query
Let me clarify how each of the points in my previous answer can help advocate for getting unit tests written:
Prioritize testing: By prioritizing testing, you are signaling to stakeholders that testing is just as important as feature development. This can help create a culture where testing is seen as an integral part of the development process, ynd while doing this you can also highlight how proper unit testing can help reduce a lot of validation efforts and potential bugs later on and help write robust code. This will lead to more emphasis on writing unit tests.
Automate testing: Automating tests can help save time and effort in testing, which can make it easier to incorporate testing into the development process. This can help demonstrate the value of testing and how it can improve product quality, making it easier to advocate for writing unit tests. In my experience automating unit testing is simpler and faster than automating end to end system tests.
Use code review: Code review can help identify issues related to testability, which can help improve the quality of the code and reduce the risk of defects. By improving the quality of the code, it can become easier to write unit tests and advocate for their inclusion.
Agile methodology: Agile development practices emphasize testing as a continuous process throughout the development cycle. By integrating testing into the development process from the beginning, it can become easier to advocate for writing unit tests as a natural part of the process.
Use Testing Metrics: Testing metrics can provide insights into the effectiveness of the testing process, which can be used to identify areas for improvement. By using metrics, you can help demonstrate the value of testing and its impact on product quality. Metrics related to unit tests can be used to demonstrate how finding issues earlier and in smaller chunks save a lot of effort and time by reducing issues occuring later on in integration and end to end testing. This would make it easier to advocate for writing unit tests.
If you, as the developer, are also responsible for your unit tests, the simple answer is: write the tests first, before your write the code!
Generally, I'd advise against the same person writing the code and then testing it, as they'll make the same assumptions in both phases, and potentially miss important edge cases.
But it seems a perverse feature of project managers (or their agile equivalents) that you'll always get some extra time to finish coding, but not to finish writing tests... so write the tests first, then get the xtra time to finish the code.