re: When do you write your tests? VIEW POST


I organize code retreat from time to time and I have been trying to practice TDD whenever I can and here's when and why I would write tests

1) when there's bug in production, I would ask is there missing unit tests?
2) when I would like to know more about functionality of the code, I try to write unit tests to make sure the code works as I expected
3) depends on how difficult it is for me to write tests for the piece of legacy code, it would tell me how much time I need to work with the code base in the long run.
4) the naming of acceptance tests/unit tests tells me how much shared understanding about the system between QA/Dev/Product Manager and this would reduce the costs of maintenance of the system very much
5) Writing tests first helps me to write simplest/minimum code that satisfies the tests. This is very true for me as I'm very lazy guy
6) As I learn more about writing tests, I realize more ways to approach problem incremental and how to deliver business value with the least amount of effort and delay as many technical decision as possible

Having said that there are still many problems with writing test first that I'm still trying to find answer

1) how do I tests build/automation/deployment scripts such as gradle, ansible, etc ... I often extracted build logic to POJO classes where I have been able to write tests and have seen reasonable success at that. However, it's not very easy for me to write tests for gradle scripts, ansible scripts. I think I would probably see more innovation in this space probably in the next 10 years.

2) I'm lucky to work with object oriented languages where it's not that difficult to break dependencies and lots of tools to help out. I'm not quite sure how easy it is to work with non-object-oriented languages.

3) As I learn more about tests, I think more and more people would like to write more acceptance tests as living specification of the systems, and I think most of the acceptance tests can be pushed down to the lowest level of tests (unit tests in Mike Cohn pyramid tests, medium.com/@ttrungvo/yet-another-i...). However the current set of tools (junit, cucumber, etc...) doesn't allow me to specify the behavior/context of the acceptance tests/specification. I hope I can see more innovation in this area.

4) It's not that easy for me to be able to write unit tests right away in the first place, I have to read a lot to learn how to break dependencies, do lots of screen casts to get better understanding at this. How can we find easier way for mass adoption? I think that because of the state of tools/practice at the moment, it's not easier for people to write tests, and this is where it prevents people from adopting TDD.

Code of Conduct Report abuse