Small intro, at this moment we are developing new system and have automation tests for web interface, unit tests for part of server side code, code reviews and sharing of knowledge in the team. Unit tests partial because of philosophy of writing valuable tests where you know what you want to validate and don't need to invent subject of validation.
We are not lunching rockets so nobody will die in case of bug. Also the aim is to get to continuous delivery and in case of bug the fix will published quickly (if it found). Applications has web client, api, many micro services and works with big databases of hundreds gigabytes of data, but we are not data creators we mostly consumers. Each service and part of application going to be continuously monitored by analytics system. Also we work with key value storages, queues and documents database. Most of logic is in database or API.
In few words nothing critical will happen in case of bug. But reputation is important too.
The questions are:
- What's yours pros and cons for working with TDD methodology
- Do TDD rises code quality? Is it true or only some legend to sell TDD?
And some personal question to everybody, don't you think that working with methodology like TDD that gives you way you have to develop your applications limits you in some frame? It looks little bit ridiculous that I can't use static variables and functions or singletons and it's only small part of the restrictions.
Thanks to all.
Top comments (5)
It would be useful to know that kind of project you are working on. How correct does it have to be? If there's an error could you kill people? Destroy a company? Lose lots of money? Get sued?
Thanks for advice I have updated the post with more details.
Thanks for adding those details.
There are lots of pro and cons resources on TDD. You just have to google it.
Pros and Cons
The biggest con is that its is slower that just writing code as quickly as you can and releasing it without much testing. So if your company is a start-up and you're racing against your burn rate to deliver 'something' or if you're basically running an experiment to try and see if there is market for the product you're building, then TDD might not align with your goals.
Next, you have to get all your developers on board and that's not always easy. You may find people arguing vigorously against TDD to cover up the fact that they don't really know how to do it. Can your company stop or slow everything down by a couple of months to get everyone trained up on TDD? If not, you might have to start with TDD on a voluntary basis and see if you can get more people up to speed over time.
The first pro is that TDD forces you to write testable software. The software produced by TDD looks much different than software written without tests. Some people complain that TDD produces tons of small classes but the TDD people think that's a benefit. The more you TDD, the closer your get to the SOLID principles. It would be really hard to write those 1,000 line methods filled with db calls, calculations, and multiple params to the method with TDD. That's a huge benefit.
The second pro is that you have automated tests for your software. You can fill in the TDD tests with more unit tests to catch the edge cases. You can change the software and re-run the tests to see if everything still works, you can use the tests as a kind of working documentation of the system. Those are pretty huge benefits.
Lots of projects get slower and slower over time as the code gets more complicated and certain areas are so dangerous to change that no one will touch them. TDD can work as your defense against that. If you never write code without tests, you should never end up with code you are afraid to change.
Does TDD raise code quality?
TDD is just a process. There's still someone sitting at a keyboard doing the typing. I can easily imagine a scenario where someone is writing TDD but still writing really low quality code. If you take a beautiful piece of code and change all the names to random strings, the code will basically be impossible to understand. TDD would not protect against that. You could also use TDD but have a really strange problem decomposition. So you can produce low quality software while still following TDD.
The other thing I've found as I'm working with someone who is learning to write tests is that beginners make mistakes. You need to make mistakes to get experience but those mistakes can be costly when you are learning while trying to write code for a production system. I've seen crazy, illogical code in a code review because someone was trying to get tests around their code. I've seen something that should have taken 3 hours, take 20 hours because the person was trying to figure out what to do to get their code tested. It takes a while to learn to write high quality code with TDD.
The research on TDD is inconclusive, but the validity of the research is questionable. There's a chapter on TDD in "Making Software: What Really Works, and Why We Believe It" (Andy Oram and Greg Wilson). I highly recommend you read it.
Most people who actually give TDD a fair chance and learn to be proficient with it think it's valuable for certain kinds of code (but not all kinds of code). WeDoTDD.com has some interesting information.
Writing software, involves making trade offs. Improving one dimension of your project will effect other dimensions. For example, more TDD probably means a later release date. TDD isn't the right choice for every circumstance and it takes experience to know when to TDD and when not to TDD.
Thank you for so detailed answer
My pleasure. Good luck with your project.