TDD Advice
-
I've decided to use TDD on my new project. It's going to be quite challenging, as it's a big project with complex testing needs. That's why I need to find out more, as much as possible, about practical TDD. I understand the concept very well, and I'm quite able to design a test fixture for arithmetic calculations, as all the available examples are so helpful to illustrate. However, good advice on factoring tests (yes, tests, not tested code) to test specific functionality, progression from simplest tests (method not found) to most complex tests (business process completed), etc. is apparently very scarce, unless I'm looking in all the wrong places. An example is: I'm implementing the logging aspect of my entire solution first. So, I write a test to write a log entry, and it fails. I add the code to actually write the entry, and the test passes. That seems very simplistic. I need tests for the validation of parameters passed to the log writing code. I need tests for exceptions generated etc. Can anyone please point me to some resources that deal with TDD on a practical level?
-
I've decided to use TDD on my new project. It's going to be quite challenging, as it's a big project with complex testing needs. That's why I need to find out more, as much as possible, about practical TDD. I understand the concept very well, and I'm quite able to design a test fixture for arithmetic calculations, as all the available examples are so helpful to illustrate. However, good advice on factoring tests (yes, tests, not tested code) to test specific functionality, progression from simplest tests (method not found) to most complex tests (business process completed), etc. is apparently very scarce, unless I'm looking in all the wrong places. An example is: I'm implementing the logging aspect of my entire solution first. So, I write a test to write a log entry, and it fails. I add the code to actually write the entry, and the test passes. That seems very simplistic. I need tests for the validation of parameters passed to the log writing code. I need tests for exceptions generated etc. Can anyone please point me to some resources that deal with TDD on a practical level?
Read "Extreme Programming Adventures in C#" or go to http://www.extremeprogramming.org/[^] I tend to cerry pick of TDD, Prince etc...
Grady Booch: I told Google to their face...what you need is some serious adult supervision. (2007 Turing lecture) http:\\www.frankkerrigan.com
-
I've decided to use TDD on my new project. It's going to be quite challenging, as it's a big project with complex testing needs. That's why I need to find out more, as much as possible, about practical TDD. I understand the concept very well, and I'm quite able to design a test fixture for arithmetic calculations, as all the available examples are so helpful to illustrate. However, good advice on factoring tests (yes, tests, not tested code) to test specific functionality, progression from simplest tests (method not found) to most complex tests (business process completed), etc. is apparently very scarce, unless I'm looking in all the wrong places. An example is: I'm implementing the logging aspect of my entire solution first. So, I write a test to write a log entry, and it fails. I add the code to actually write the entry, and the test passes. That seems very simplistic. I need tests for the validation of parameters passed to the log writing code. I need tests for exceptions generated etc. Can anyone please point me to some resources that deal with TDD on a practical level?
You might want to look at the Yahoo TDD Group: http://groups.yahoo.com/group/testdrivendevelopment/[^]. :)
Anna :rose: Linting the day away :cool: Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
I've decided to use TDD on my new project. It's going to be quite challenging, as it's a big project with complex testing needs. That's why I need to find out more, as much as possible, about practical TDD. I understand the concept very well, and I'm quite able to design a test fixture for arithmetic calculations, as all the available examples are so helpful to illustrate. However, good advice on factoring tests (yes, tests, not tested code) to test specific functionality, progression from simplest tests (method not found) to most complex tests (business process completed), etc. is apparently very scarce, unless I'm looking in all the wrong places. An example is: I'm implementing the logging aspect of my entire solution first. So, I write a test to write a log entry, and it fails. I add the code to actually write the entry, and the test passes. That seems very simplistic. I need tests for the validation of parameters passed to the log writing code. I need tests for exceptions generated etc. Can anyone please point me to some resources that deal with TDD on a practical level?
As you hint most of the books and articles on TDD are long on simple examples that show TDD in its best light but short on real world situations which are messy. Anna's suggestion is best, get into a public group that discusses TDD and start doing TDD. You'll end up refactoring a lot the first time, and the second and third. You can always try and ask TDD questions here, we do it were I work and others on CP are doing it too.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
I don't see it happening, at least not until it becomes pointless.
-
I've decided to use TDD on my new project. It's going to be quite challenging, as it's a big project with complex testing needs. That's why I need to find out more, as much as possible, about practical TDD. I understand the concept very well, and I'm quite able to design a test fixture for arithmetic calculations, as all the available examples are so helpful to illustrate. However, good advice on factoring tests (yes, tests, not tested code) to test specific functionality, progression from simplest tests (method not found) to most complex tests (business process completed), etc. is apparently very scarce, unless I'm looking in all the wrong places. An example is: I'm implementing the logging aspect of my entire solution first. So, I write a test to write a log entry, and it fails. I add the code to actually write the entry, and the test passes. That seems very simplistic. I need tests for the validation of parameters passed to the log writing code. I need tests for exceptions generated etc. Can anyone please point me to some resources that deal with TDD on a practical level?
Brady Kelly wrote:
I've decided to use TDD on my new project. It's going to be quite challenging, as it's a big project with complex testing needs.
I hope you don't need this project to put food on your table. IMHO, TDD means "do TDD for the riskiest 10%~20% of your project, do decent unit and regression tests for the rest".
-
I've decided to use TDD on my new project. It's going to be quite challenging, as it's a big project with complex testing needs. That's why I need to find out more, as much as possible, about practical TDD. I understand the concept very well, and I'm quite able to design a test fixture for arithmetic calculations, as all the available examples are so helpful to illustrate. However, good advice on factoring tests (yes, tests, not tested code) to test specific functionality, progression from simplest tests (method not found) to most complex tests (business process completed), etc. is apparently very scarce, unless I'm looking in all the wrong places. An example is: I'm implementing the logging aspect of my entire solution first. So, I write a test to write a log entry, and it fails. I add the code to actually write the entry, and the test passes. That seems very simplistic. I need tests for the validation of parameters passed to the log writing code. I need tests for exceptions generated etc. Can anyone please point me to some resources that deal with TDD on a practical level?
Hi. I'm using TDD 1 year already & discovered its importance not by rumors, so you are on the right way. From my experience(not so great experience of course - only 1 year) I can say that it would be great if you would just test each form on opening, closing and saving (if you have any forms of course 8)). These litte tests will help get rid of overwhelming majority of bugs & errors. Especially when you are dealing with applications working with databases. Good luck!
-
As you hint most of the books and articles on TDD are long on simple examples that show TDD in its best light but short on real world situations which are messy. Anna's suggestion is best, get into a public group that discusses TDD and start doing TDD. You'll end up refactoring a lot the first time, and the second and third. You can always try and ask TDD questions here, we do it were I work and others on CP are doing it too.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
I don't see it happening, at least not until it becomes pointless.
I have joined the yahoo group Anna recommended. I think I'll just do what seems best, and keep asking questions. I'll ask one here now though. My first iteration of development is to implement security and logging features in all components, so I assume my first tests will be actually testing the interface, i.e. can I call the method. So I write a test that fails if the method doesn't exist. This is possible because the method is a CLR stored procedure. Then I build and deploy the procedure, to make the test pass. Then I should test input validation: do I get the expected exception if I omit a parameter. Then I add the parameters until my test passes. Then I write a test to fail because my code doesn't have the necessary permissions, then to check if a log is written when it fails for that reason. Am I on the right track? Do I write an individual test for each parameter in the validation tests, or just test for all params together?
-
Brady Kelly wrote:
I've decided to use TDD on my new project. It's going to be quite challenging, as it's a big project with complex testing needs.
I hope you don't need this project to put food on your table. IMHO, TDD means "do TDD for the riskiest 10%~20% of your project, do decent unit and regression tests for the rest".
My employer needs this project to put food on all our tables, but it's not a very complex project. I'm confident I can apply TDD to it without excessive complications. If it doesn't work out I can always fall back on plain pre-build unit testing.
-
Hi. I'm using TDD 1 year already & discovered its importance not by rumors, so you are on the right way. From my experience(not so great experience of course - only 1 year) I can say that it would be great if you would just test each form on opening, closing and saving (if you have any forms of course 8)). These litte tests will help get rid of overwhelming majority of bugs & errors. Especially when you are dealing with applications working with databases. Good luck!
It's all a back-end application. I need to test database, MSMQ, and web services, but no forms.
-
I've decided to use TDD on my new project. It's going to be quite challenging, as it's a big project with complex testing needs. That's why I need to find out more, as much as possible, about practical TDD. I understand the concept very well, and I'm quite able to design a test fixture for arithmetic calculations, as all the available examples are so helpful to illustrate. However, good advice on factoring tests (yes, tests, not tested code) to test specific functionality, progression from simplest tests (method not found) to most complex tests (business process completed), etc. is apparently very scarce, unless I'm looking in all the wrong places. An example is: I'm implementing the logging aspect of my entire solution first. So, I write a test to write a log entry, and it fails. I add the code to actually write the entry, and the test passes. That seems very simplistic. I need tests for the validation of parameters passed to the log writing code. I need tests for exceptions generated etc. Can anyone please point me to some resources that deal with TDD on a practical level?
Our very own CP has this article Clickety[^] that I used to get started on TDD.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before. -
I've decided to use TDD on my new project. It's going to be quite challenging, as it's a big project with complex testing needs. That's why I need to find out more, as much as possible, about practical TDD. I understand the concept very well, and I'm quite able to design a test fixture for arithmetic calculations, as all the available examples are so helpful to illustrate. However, good advice on factoring tests (yes, tests, not tested code) to test specific functionality, progression from simplest tests (method not found) to most complex tests (business process completed), etc. is apparently very scarce, unless I'm looking in all the wrong places. An example is: I'm implementing the logging aspect of my entire solution first. So, I write a test to write a log entry, and it fails. I add the code to actually write the entry, and the test passes. That seems very simplistic. I need tests for the validation of parameters passed to the log writing code. I need tests for exceptions generated etc. Can anyone please point me to some resources that deal with TDD on a practical level?
Look for 'Test Driven Development By Example', by Kent Beck. He actually reviews his approach using real world situations.
-
I have joined the yahoo group Anna recommended. I think I'll just do what seems best, and keep asking questions. I'll ask one here now though. My first iteration of development is to implement security and logging features in all components, so I assume my first tests will be actually testing the interface, i.e. can I call the method. So I write a test that fails if the method doesn't exist. This is possible because the method is a CLR stored procedure. Then I build and deploy the procedure, to make the test pass. Then I should test input validation: do I get the expected exception if I omit a parameter. Then I add the parameters until my test passes. Then I write a test to fail because my code doesn't have the necessary permissions, then to check if a log is written when it fails for that reason. Am I on the right track? Do I write an individual test for each parameter in the validation tests, or just test for all params together?
Brady Kelly wrote:
Am I on the right track? Do I write an individual test for each parameter in the validation tests, or just test for all params together?
Strict TDDers would say a test for each possible route. I'd say use your head and don't be too concerned with what the strict TDDers say. You may end up disliking and not using TDD if you follow its every letter. Same applies for a lot of programming really, know when to take a shortcut, be aware of the consequences and weigh them up with the cost of doing it each way. Something like a login though I'd write multiple tests because the number or routes is not so huge based on the params. Multiple tests make it easier to track what broke what. But they are slower and harder to maintain. A function that takes 10 parameters with many possibilities each though I'd group the main routes into single tests. Something higher level than each possible route as an individual test. And sometimes you will break the Test First rule. It isn't a sin, just know what you are doing.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
I don't see it happening, at least not until it becomes pointless.
-
Brady Kelly wrote:
Am I on the right track? Do I write an individual test for each parameter in the validation tests, or just test for all params together?
Strict TDDers would say a test for each possible route. I'd say use your head and don't be too concerned with what the strict TDDers say. You may end up disliking and not using TDD if you follow its every letter. Same applies for a lot of programming really, know when to take a shortcut, be aware of the consequences and weigh them up with the cost of doing it each way. Something like a login though I'd write multiple tests because the number or routes is not so huge based on the params. Multiple tests make it easier to track what broke what. But they are slower and harder to maintain. A function that takes 10 parameters with many possibilities each though I'd group the main routes into single tests. Something higher level than each possible route as an individual test. And sometimes you will break the Test First rule. It isn't a sin, just know what you are doing.
regards, Paul Watson Ireland & South Africa
Shog9 wrote:
I don't see it happening, at least not until it becomes pointless.
Thanks Paul, and everyone else. I'm going to dive in, as it seems I have some time for this project, and there's nothing like learning in the real world. When I bought my motorbike in November I hadn't ridden one for 12 years, and I rode it out the shop straight to work on the freeway. Got used to it very quickly, and I think the TDD will pan out like that.