21–30 of 89 posts
I'd say really invest time creating a productive TDD environment for yourself first before attempting to convince business people. Buy into the dogma for several months. This should really give yourself an idea of the pros and cons of TDD.
However, I tend to write tests very early as soon as some code runs. Why? Because without tests I would feel like driving a car at night without lights and with no brakes. Sooner or later I'll crash into something and discover that I'm way out of route.
The reason is the same if you do proper TDD.
I also use test coverage tools, to know what I'm not testing. Sometimes is not important, sometimes it is. Given constraints on time and budget it's important to have data to back the trade off you must make.
(Question to native English speakers: you do a trade off or you make one?)
About those 40 minutes: it's way too much. Even 4 minutes could be too much. Is your application that big or are you testing its parts many times with different tests? Maybe you could slim down the test suite. Unit tests for the single components and an integration test for all the application. In the case of a web application you would use one of the many tools that drive a real browser through all the pages of the app, one test per use case. That could be slow but the unit tests would be fast. You can run the unit tests on your computer and the integration test on a continuous integration server.
Edit: -do +make trade off
I tried some projects with TDD, but unfortunately, it is too counter intuitive for me to follow to design a system.
1) Development is not really slowed down by any meaningful amount. You might invest more time up front, but further development is faster. The time investment in unit tests at the beginning pays for itself very quickly. With anything of a reasonable size, especially anything that involves multiple developers, the unit tests will speed up development over all.
2) The obvious one; you find bugs faster. If you write thorough and good test suites, you will find bugs before you release the code (obviously) and you will find bugs when you go back and touch the code again. I'm not going to claim you'll find every bug and never release a bug into the wild again, because that's not true, we're human. But things will be vastly better.
3) Maybe most importantly, it forces you to think about your code more and write better code. In order to make your code properly testable that will mean that your code has to be properly divided up into testable units. That means goodbye monolithic code, hello division of concerns.
It's silly but if you're having a hard time convincing management, sometimes they respond to the fact that any "serious" development team at a "real" enterprise writes unit tests. Managers are sometimes very susceptible to pointing out that they're doing things in an amateurish way, because they like to think of themselves as professionals.
Strictly speaking I don't do TDD because I don't write tests first. I write code first, then I write the tests. If I went tests first sometimes I would have to design the algorithm anyway because I wouldn't know what to test. However, I tend to write tests very early as soon as some code runs. Why? Because without tests I would feel like driving a car at night without lights and with no brakes. Sooner or later I'll c…
Taking 40min for the unit tests to run points to a problem, however, I've seen my fair share of "TDD geniuses/advocated" that love doing things that slow everything down (like writing hundreds of minuscule testings where 2 or 3 things could be tested in the same test, big setup methods, etc)
Hmm, having a test do anything more than one thing sounds like a functional or integration test.
Suppose you want to test a function that capitalizes the first letter of words in a string: I would test
'' => ''
'a' => 'A'
'aa bb' => 'Aa Bb'
3 tests, which does not mean 3 functions (that will have the overhead of setup and teardown)
#1 A change in your current process must be "sold" in the business context of $$savings (faster dev cycle, lower number of bugs, lower cost of support) or increase in developer productivity/utilization or increase in customer satisfaction. #2 Inadequate unit testing almost always correlates to greater defects in the support/maintenance cycle. So I would recommend gathering some data around it: for e.g., number of ope…
Here is 1 of many good Uncle Bob articles on TDD - http://blog.cleancoder.com/uncle-bob/2016/03/19/GivingUpOnTD...
This quote from the article is slightly off topic, but I think it is a great one you could tweak & use with Management:
"Look. Suppose you ask me to write an app to control your grandmother's pacemaker. I agree, and a week later I hand you a thumb-drive and tell you to load it into her controller. Before you do you ask me: 'Did you test it?' And my response is: 'No, I chose a design that was hard to test.'"
1. There is a difference between selling unit tests and selling a development method that is guided by writing the unit test first. Unit tests are great for providing self-documenting code and examples. A developer can look at the test and see what is expected to use the code. Unit tests run quicker than integration tests, but both are needed. (With the right unit tests, you need a fraction of the slow tests.)
You sell unit tests as extending the life of the product by years because the developers in ten years will understand how the system works by its tests.
2. You sell test driven development to developers by doing it with them, side by side, and observing the output in the end. Test driven development is also called test driven design. By writing the test, making the test pass, and then clean up the code, you get a quick iteration loop that allows you to make changes as you go and know your tests have your back.
An experienced TDD developer develops at the same speed as a non-TDD developer, because the TDD developer develops the toolkit to write tests quickly. They get caught less in analysis paralysis because they can just make a change, see what it looks like, and know if it works because their tests pass or fail.
But just like when someone learns another programming paradigm, it takes time to get there. TDD is slow for most people because they never get good at TDD.
The disadvantage to those code bases is that making a design change can sometimes feel slower because the time to read the existing tests, understand which breaks need to be addressed by code and which need to update the test -- that can be drudgery. I've lived in 100% unit test code bases and it can be irritating to make a big change.
(Some TDD advocates say that your tests should never break, and you should work in abstractions that ensure that your tests never break. This can lead to designs I don't prefer and really weird intermediate states.)
My personal opinion? If you're in dynamic languages, you need more tests than in a statically typed language. If you're in a functional language, you need fewer tests still. The more your compiler will do for you, the fewer tests you need.
my personal style to design a system is to focus on design the domain model, I believe that this is an intuitive way for people to design stuff (not just software, also in math and ML). This is the reason why I am not sold by TDD which start with writing test cases first – how come people can tell what is going to test before they know what they are going to develop. I tried some projects with TDD, but unfortunately,…
Write your test as if the perfect domain model existed already, and then make it work. E.g. does it make more sense to write person.Age = 21, or person.Birthday = someDate. Alternatively, taking your math example, your tests are the constraints of an equation that your code solves.