Typically, the main reason for me to do code retreat to help developers in the community to expose more to TDD/craftsmanship.
Recently, I asked myself the question: “How come it’s not easy to adapt TDD, automated testing which should be the core value of any efficient team?” I don’t think that people is lazy or people is resistant, I think as the industry, there’s lots of ambiguity in how people should approach TDD (SOLID principles, 4 simple rules of design, etc … are too generic) and agile practices (agile manifesto, etc…)
Furthermore, How can I apply SOLID, 4 simple rules of design into my day to day jobs?
What’s the most important reasons for developers to write automated tests? is it testability design, is it executable documentations?….
what’s the different between integration/component/API tests? should we care?
when I discuss unit tests with QA, typical answers I get is that it’s programmer tests? IT’S SO NOT TRUE? It does contain many behaviors of the systems, some behaviors are at very low level and business people shouldn’t care about, but I believe MOST OF THE BEHAVIORS could and should be expressed at high level domain language and can be used as executable documentation for different stakeholders such as QA/Non technical people. Should we call those tests as behavior unit tests instead of unit tests?
How can we make the TDD/Refactor/agile practices easier for people to adapt?
- Maybe, shrink the change?
- Maybe, there’s lots of things can go wrong but there’s few things that you got to get it right, so script critical moves?
- Maybe, Looking for bright spot (examples) so people can see the benefits and start small?
- Maybe, tweak the environments to encourage the right behavior and discourage the wrong behavior?
I think code retreat is one of the good place for me to find the answer to that question.