TDD Survey 2017
The aim was to uncover any patterns in usage, and discover issues that people face.
The survey was sent out via my personal twitter and facebook feeds. It was also sent the link out via codebar slack notifications and to brighton alt.net. The spread of developer experience was fairly mixed. However, it would have been good to add a section to the questionnaire to explore that.
The most popular opinions were:
- I use TDD often at work. 42%
- I find it useful, I wish we used it more. 61%
- Best when developing a brand new project with no dependencies 8.2 / 10
- When I code I write a test and then some code to make it pass, refactoring when it passes. 40%
- It’s a bit slower for me to do TDD, but it saves time in the long term. 61%
The results from 36 responses:
1.When have you used TDD?
- For all production code and other more full-fledged code.
2.How do you rate TDD in general?
3.How do you rate using TDD in the following scenarios?
4.When you code, how do you generally check it works?
- it varies a great deal, depending on the problem I am trying to solve.
- It depends on context and language. In Haskell, it’s not much required, but a few tests after the fact are appropriate. Usually, if it compiles, it works. In F#, sometimes test-first works best, but sometimes, again, test-after is better, because the trick is to get the code to compile. In C#, TDD is a must for me. I don’t trust C# without tests.
5.How much longer does it take you to use TDD?
6.Describe your own experience of TDD in a few sentences
- Makes solutions simpler and easier to maintain.
- I like out side in aproach as it keeps you on things that are important. TDD is a different mindset. People only realise that when they are used to this approach.
- I find TDD most useful for refactoring.
- Sometimes it’s hard to do it in a legacy codebase
- Safety, I know when I broke stuff. I can’t think of details upfront, I discover them as I test drive the code.
- Ultimately TDD is one tool of many in developing – it’s gone a bit out of fashion with having much faster deployment cycled (with continuous deployment). Hugely useful in terms of documentation and confidence when refactoring, but the biggest curve is having to know what you want to build up front.
- In my opinion, TDD helps you: – Make incremental progress by slicing things to smaller chunks – Write enough code than coding and keep on coding – Confidently refactor – Communicate the intent of the code, if tests are written well – Lastly, to capture regression issues and deliver confidently
- cyber-dojo.org is the place to go for groups wanting to practice TDD
- I tend to refactor several times to get the types I want, and then add tests at the external interface of the API for cases where the types can’t “make illegal states unrepresentable”. TDD can in contrast be very useful when working with very dynamic data which is not easily described in the exact logic of a type system, such as refactoring legacy code (where the original intent has been lost!) or dealing with “messy” data such as parsing user input.
- The more logic, the more helpful I find TDD.
- I’ve found TDD (test-first, one test at a time, writing just enough implementation code to make the test pass, then refactor, then move on to the next test) particularly helpful when working alone, or as a documentation device (reading through a well-written test helps understand the intended functionality of the code). I’ve had some trouble being disciplined enough to apply the “refactor” part of the red-green-refactor cycle, as I’m usually impatient to move on to the next test. This way, refactoring work tends to pile up and become less manageable. Also, while I know that the cycle mentioned above should also include a fourth phase (refactor the *test code*), I rarely if ever do it, so the test code usually remains just how it was written. I also see a problem with tests that were useful during the TDD process itself (to help guide the implementation) but don’t add any value once the implementation is completed. Those tests should be removed, but here, again, I lack the discipline to do so. This can lead to a bloated, slower test suite. Finally, especially with a new language or framework or even a new dependency it can take quite some time before the TDD process feels fluid, i.e. before the test harness is set up properly, such that testing can occur after every tiny change, at the push of a button.
- It makes you really think about your code.
- useful but time consuming
- It’s surprising just how fast I get lost and have seemingly unsolvable bugs when I write code without tests!
- Its enormously useful for focusing my thoughts on defining the problem I’m trying to solve, on solving the problem and breaking up the problem into small chunks. It’s also very useful when adding new features, changing the code in some way and debugging.
- I think it’s most useful when you have a specific goal in mind, and you have a good idea what your approach is going to be. If you’re implementing a new feature and have no idea at all how you’re going to do it, I think you’ll spend just as much time (if not more time) editing the initial tests you wrote than the time it took to implement the feature’s code
- Useful in OOP. Not quite so much in statically-typed functional languages.
- Good when you know the domain problem enough Can get in the way if not, I like to prototype first in this case
- I really enjoy it when I do it, but find setting up suitable test data is often a blocker, and needs careful consideration. Often come across tests written by others that are brittle – meaning I end up taking longer to make changes as I have to fix those tests too.
- Reading about it makes me jealous and I want to use it in my job.
- Very useful for bug fixes. Difficult to encourage others to use + needs to be part of team culture to work
Thanks to all that contributed. Please find the survey here if you wish to add to it. Also, feel free to add comments below, perhaps on your interpretation of the results?