Test Driven Development (TDD)

[brad jones]

We posted an article on Developer.com on Test Driven Development (TDD).

http://www.developer.com/design/article.php/3622546

This topic has come up quite a bit in recent months in discussions I've been having with developers. I'd be curious to know if any of you are doing TDD and if it is working for you.

Brad!

[bobabot1]

I think this is a great idea!

One question. Is this board soley for the discussion of tools like Visual Studio Team System Tester Edition or can it be a call to beta testers and that sort of thing?

[brad jones]

One question. Is this board soley for the discussion of tools like Visual Studio Team System Tester Edition or can it be a call to beta testers and that sort of thing?

This forum is to discuss all things testing. It does not have to be Microsoft's tools, but rather can be any testing tools, topics, or things that help make testing and Quality Assurance work.

This forum is not for getting beta testers or soliciting help with testing. That would be the Open Positions forum area (http://www.vbforums.com/forumdisplay.php?f=53).

This particular thread is actually for discussing Test Driven Development.

Brad!

[RhinoBull]

I've seen one of those AddIns in "action" (I think it was called VBTestUnit or so).
Guys in our shop after much debate decided that it was not for us but rather for someone who is "one man does it all" and/or also is a lousy tester. :)
We came to conclusion that we could not rely on Mr. Wizard by all mean.
As a developer you must understand what you're doing regardless of complexity and be responsible for the result(s).
But again - opinions vary...

[brad jones]

As a developer you must understand what you're doing regardless of complexity and be responsible for the result(s).
But again - opinions vary...

in my opinion....

Nothing about testing or having testers removes this responsiblity. In fact, I could argue that having testers and doing formalized testing can actually put more pressure on a developer to test and make sure their code is clean because others in a (likely) formalized processes are going to be reviewing what they've done.

Additionally, testing serves other purposes too. It can help to make sure that if someone else's code changes, that it doesn't break yours. By having testing rules and testers, you can have in place processes to review all the critical functionality if something changes so as to validate that things are okay (hence the reason I see Quallity Assurance (QA) as a part of testing as well).

Brad!

[mendhak]

I'm using TDD, but being unaware of the acronym. Must be a marketing thing.

It works, but one must take into account the perspective of the developer rather than the project manager. Since the article mentions the advantages, I'll not add any of my own. I'll just mention problems

1. It can be a hinderance at times, it slows me down when I need to work on a tiny module but when the rule is that you must Nunit it.

2. It has a long, long, long way to go. It doesn't work in all cases, especially when it comes to web development. Example, when working with WebRequests, or more importantly, when working with a heterogenous data source that the application interfaces with, an example off the top of my head: XML repositories that involve XQuery/XPath, considering that they are scripted/structured languages. In such cases, it's come down to more of manual testing just to make sure that the page works right. In other words, I find the scope of TDD very narrow and can prove to be a problem in projects that involve such scenarios if the manager doesn't know what he's doing. Which is the case, half the time.

[Merrion]

The most important aspect of TDD is that you write the tests first and only when the tests are written do you write any application code which gets tested....

However it does mean that if the tests aren't right then the resulting code won't be right so an extra and non-trivial problem needs to be addressed: how do we verify that the tests are valid? The "hello world" type examples of TDD all work with such simple problem domains that this is not obvious, but how do you write a test for something non trivial like: "The clients exposure to non exchange traded swap contracts must not exceed 30% of their book assets"?

[disruptivehair]

in my opinion....

Nothing about testing or having testers removes this responsiblity. In fact, I could argue that having testers and doing formalized testing can actually put more pressure on a developer to test and make sure their code is clean because others in a (likely) formalized processes are going to be reviewing what they've done.


Oh, definitely; you'd rather test your own stuff than have a tester run up to you breathlessly and tell you excitedly about all the mistakes you made. I ought to know, I used to be that tester. :blush:

[mendhak]

If you're anything like the testers we have, you drag the developer all excited back to your machine, only to realize you missed an item in the listbox... and I smile contentedly. :)

[disruptivehair]

If you're anything like the testers we have, you drag the developer all excited back to your machine, only to realize you missed an item in the listbox... and I smile contentedly. :)

Nah, that didn't happen very often after the first year I spent in QA. :thumb: Usually if I found a bug it was a proper bug and not a 'feature' or a user error. :bigyello: