[wordswords]

I'm giving a talk tomorrow for some students of Manchester University on Test Driven Development (TDD). I wondered how many people here actually use TDD in their day-to-day work. It can be seen as a dogmatic or restrictive approach, but it's one that I think definitely increases code quality. What are your thoughts/opinions?

[sas1ni69]

It seems ignorant that I know about it and it's benefits but have yet to really use it on a long term project. I've done some testing with it. I haven't started "liking" it yet cause it seems to be very time consuming.

[runfaster]

The job I just started really promotes this style of coding, but didn't use it at all in college. Thus, I put "No, (some other reason).

It's quite a struggle to try and flip your mindset to test-driven when you're not used to it, but I can certainly see the benefits. Knowing what you have to satisfy, test-wise, is definitely a good way to approach a development problem. I'm definitely going to try and use it going forward.

This post has been edited by runfaster: 12 February 2013 - 07:21 PM

[seriousazn]

I'm just starting to learn about programming, and I guess it's lucky for me that my teacher is focusing on test-driven development even though it seems tedious... Would be awesome if you could share some key points from your talk.
Thanks!

[Sergio Tapia]

Yes, at my job we use unit tests and test driven development. We test our code base, and our front end code. NUnit and Selenium.

[Skydiver]

One of the subtle effects of TDD is that it encourages writing code that loosely coupled with tight cohesion. To me this is a good thing. I get a good indicator that I am writing tightly coupled code if it gets harder and harder to write tests because I need to do more and more setup for any given test.

Another effect of TDD is that it cuts down on analysis paralysis and feature creep. If I am holding true to TDD principles, I should be writing the minimum amount of code to make tests pass. I shouldn't be designing for far off what-ifs. I should be writing tests that mimic how the code will be used now. This accelerates development.

If ever I get to that point where I need to support one of those what-if features, then I write a new test to test the new feature and work to make that new feature test succeed while keeping the already existing tests working. This accelerates development as well because I have assurance that I am not creating regressions when I add the new feature.

[Sergio Tapia]

It helps if you're using something that highly encourages unit testing, like Ruby on Rails.

[jon.kiparsky]

I've had to make a conscious effort to incorporate TDD in my work, and I've been more slack on this than I ought. This does not make me a good example!

One thing I've noticed as I use more python, though, is sort of the opposite of Skydiver's experience: writing shorter functions with looser couplings generally means that I'm a lot less concerned about bugs, because there is almost no place for them to hide. So I certainly could do more testing, and it would be easier under this model, but at the same time it seems a lot less pointful because a five-line function with no external dependencies is pretty easy to test "by eye".*

Again, I don't say this is good practice, and certainly it doesn't scale well, but it's where I'm at right now. For larger projects, the likely point of failure will likely be in the function calls, not the functions' functionality.

The thing I lose by this, of course, is the watchdog effect, which seems to me the most important argument for TDD. I can break my programs by changing them, and TDD would at least give me confidence that I hadn't broken anything I'd tested for.

* Aside: One way to justify small, loose functions is as a tricky way around Dijkstra's observation that no non-trivial program can be proved error-free. Small, self-contained functions are in fact trivial programs and can be proved correct. This does not prove the program as a whole but it gives us a basis for improved confidence.


EDIT: BTW, if there is any sort of recording of your talk, I hope you'll post a link to it. I'd like to see what you have to say on the subject.

This post has been edited by jon.kiparsky: 12 February 2013 - 09:06 PM

[Nakor]

I've been trying more and more to get into TDD. At work I think I would be only person who would even know what it is without having to look it up. I really think there are a lot of benefits to be had from using TDD, I just find myself wanting to jump straight to the code though rather than writing tests. I really need to start making a conscious effort to retrain my brain.

As others have said, it would be interesting to see any notes/video that comes from this talk.

[Martyr2]

I don't officially do TDD but you know, I think that is ok. In my own little way I already do some of the founding principles of TDD. When a bug comes in, I try my best to reproduce the bug. Once I see the bug appear I then run it through other tests to see when it disappears. I do this until I find out what exactly is making the bug happen and diagnose the problem. Then I go in and correct it.

Afterwards I just do the tests again. The difference I do from TDD is that I don't do anything formally. I figure if I can get to the point of truly understanding the problem then all the overhead of testing in a TDD manner is really wasted time.

I think in some ways TDD is again treating symptoms and not really the problem. If you understand the problem, most of the time the programmer knows exactly what they must do to correct the problem.

As for additional features, well I can see TDD being a bit more productive. But then again I am usually on the thought that if you design the system well to start any additional feature should be easy to implement and highly decoupled.

Just some thoughts. They may be the right or wrong way to go, but it has worked out for me.

This post has been edited by Martyr2: 13 February 2013 - 11:11 AM

[jon.kiparsky]

Quote

They may be the right or wrong way to go, but it has worked out for me.

I don't see that there's anything gained by thinking of it as "right way" and "wrong way". Rather, it's "does this make me more effective, and is it worth the tradeoffs?". It seems to me that you're pretty effective - just from reading your posts - so maybe you're okay with what you're doing now. Moving to TDD requires a lot of effort, you have to re-configure the way you work, so there's a short-term trade-off (you're less effective while you're learning to be a TDD developer) and there's a risk it might not add a lot to your effectiveness, so maybe it doesn't pencil out for you. That's cool - it's just one more tool in the bag.

Quote

I think in some ways TDD is again treating symptoms and not really the problem. If you understand the problem, most of the time the programmer knows exactly what they must do to correct the problem.

The thing that you're leaving out here is the "watchdog" property: Under TDD, your tests are persistent, and they catch future errors and not just past ones. As I say, I'm more in line with your way of working, but if there's one feature that seems like a real silver bullet, that's it.
Good design reduces complexity, and that's a good thing and it makes development easier, so the same developer working on a good design can manage a program that is more complex by some large factor. (however you measure these things) However, what this really buys you is the ability to work on larger programs in about the same way you worked on smaller programs pre-TDD.
The implicit promise of TDD is a qualitative difference: now you have a guarantee that certain mistakes will warn you when you make them. When I do work in test-driven mode, this completely changes my approach to the work. In a way, it's like moving from saving to the filesystem to version control - everything changes.

So why don't I do it? Mostly because it's not a habit, I guess. It takes a certain amount of self discipline to think all the way through a problem and then hold off solving it while you write tests. That's hard for me to do, honestly.

This post has been edited by jon.kiparsky: 13 February 2013 - 11:53 AM

[lordofduct]

I wouldn't say I commit completely to a Test Driven Development process.

Not all the code I write can benefit from the expense it takes to do this. That or the code is so routine that I have no need to test it in such a granular way. I can just jam it out and throw it at QA.

I do sometimes get the job of writing new technologies for the office. Not often as our main objective currently isn't new technologies, but instead bringing our aging technologies into the modern market.

But when I get to write new technologies, I benefit greatly from TDD. I may not follow an orthodox form of it, but it's still test driven.

[ishkabible]

I write unit test but I can't say that I actually follow TDD.

[tycos]

I have worked on projects that have used Cucumber tests, Ruby on Rails, I am sure we wrote too many tests at times and running all of them took ages!

Watching some dev videos recently I would be more inclined to use unit tests, when writing these tests what you write often becomes part of the classes you use in the final code so you don't feel you are wasting time.

Where any kind of tests really help is when many people are all on a single project and pushing new features out often, it becomes hard to ensure you don't break parts of a system you have not worked on.

So I do use it sometimes and have mixed feelings about it.

[BobRodes]

It does require more up front overhead, but maintenance is easier. Integration testing is considerably easier due to being able to automate a lot of it.