When I use to write tests last, I didn't have task aversion because I valued the feedback I would get on my work, as I too consider myself a mere mortal. However, where I did face task aversion is where the testing infrastructure was more complex than the code itself, and not for good reason. Or when unit tests were created for god like classes because of ci/cd code coverage requirements.
So I think it's important that the test code of the application is in a good state for developers to not face this aversion and for the metrics being tracked to mean something.
Also, I think you read my mind here, "When I write a list of pending tests first, I also have a better expectation of what’s left in my work."
I've noticed when practicing TDD, I become more confident in the scope of the work to be accomplished once my tests are written. Once the tests are written I have the short feedback mechanism in place to guide my development, I have a deeper understanding of the business problem as I'm being forced to think about the problem from perspective of the user and I'm more confident about the design as it will raise a red flag to me if it's hard to use.
I think the acceptance level tests is really what gave me that confidence, a high level test that was interacting with the system like a client would. I was more confident that it would work as expected and that I wasn't missing something.
The acceptance test would ground me to reality in ensuring that I was implementing the solution that solves a real business problem and the unit tests would allow me to more granularly iterate and achieve comprehensive correctness.
Now that I'm thinking about it, I think potentially one of the main reasons the testing code got to the state it was in, was because of the task aversion company culture. Whether that's delegating tests to be almost exclusively test-after by a separate team that is less technically experienced or because the devs didn't care in the first place about the quality of the tests.
Hey Wisen,
When I use to write tests last, I didn't have task aversion because I valued the feedback I would get on my work, as I too consider myself a mere mortal. However, where I did face task aversion is where the testing infrastructure was more complex than the code itself, and not for good reason. Or when unit tests were created for god like classes because of ci/cd code coverage requirements.
So I think it's important that the test code of the application is in a good state for developers to not face this aversion and for the metrics being tracked to mean something.
Also, I think you read my mind here, "When I write a list of pending tests first, I also have a better expectation of what’s left in my work."
I've noticed when practicing TDD, I become more confident in the scope of the work to be accomplished once my tests are written. Once the tests are written I have the short feedback mechanism in place to guide my development, I have a deeper understanding of the business problem as I'm being forced to think about the problem from perspective of the user and I'm more confident about the design as it will raise a red flag to me if it's hard to use.
I think the acceptance level tests is really what gave me that confidence, a high level test that was interacting with the system like a client would. I was more confident that it would work as expected and that I wasn't missing something.
The acceptance test would ground me to reality in ensuring that I was implementing the solution that solves a real business problem and the unit tests would allow me to more granularly iterate and achieve comprehensive correctness.
Now that I'm thinking about it, I think potentially one of the main reasons the testing code got to the state it was in, was because of the task aversion company culture. Whether that's delegating tests to be almost exclusively test-after by a separate team that is less technically experienced or because the devs didn't care in the first place about the quality of the tests.
Thanks for sharing your experience, Ben! That resonates. When testing code is not treated as a first-class citizen, it tends to rot.