Test Driven Dev
-
I don't understand the hype surrounding TDD. Many people tell me that it's the greatest thing since sliced bread, but I've never used it and I get by just fine. According to the "Best Practices" commitee at my current client, TDD is really important. I have built them a large suite of applications, based on a huge business object framework completely rolled from scratch (around 30-35k lines), and there isn't a line of test code involved, except for Debug.Assert()s and checks for null. The apps work famously and there are hardly ever any bugs reported, maybe three or four minor tweaky issues have cropped up since I've been there (8 months). So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit. :josh: My WPF Blog[^]
>>why on Earth should I spend a large amount of my time building tests? how much time do you* spend looking at those debug.assert messages and manually clicking around in your app? the wole point of unittesting is to spend _less_ time writing test than you would spend manually testing it by clicking around in the application. you cant just look at it from the initial development view , "oh I write tests for everything and it takes twice as long" , you have to look at the whole lifecycle of the app , including maintenance and adding new features. the nice thing about it is that if you refactor or add a new feature , you can run your tests and see if anything got messed up. with your debug.asserts , you cant just tell your app to run all those , you'd have to click through every little part of your app to see that nothing got affected by your new code. //Roger ps. * "you" in this case is you and your QA team and everyone else that is responsible for delivering a solid app. http://www.puzzleframework.com
-
>>why on Earth should I spend a large amount of my time building tests? how much time do you* spend looking at those debug.assert messages and manually clicking around in your app? the wole point of unittesting is to spend _less_ time writing test than you would spend manually testing it by clicking around in the application. you cant just look at it from the initial development view , "oh I write tests for everything and it takes twice as long" , you have to look at the whole lifecycle of the app , including maintenance and adding new features. the nice thing about it is that if you refactor or add a new feature , you can run your tests and see if anything got messed up. with your debug.asserts , you cant just tell your app to run all those , you'd have to click through every little part of your app to see that nothing got affected by your new code. //Roger ps. * "you" in this case is you and your QA team and everyone else that is responsible for delivering a solid app. http://www.puzzleframework.com
Roger J wrote:
"you" in this case is you and your QA team and everyone else that is responsible for delivering a solid app.
For better or worse, I am the only person involved with creating this application suite. That makes testing it easier, in some ways, because when a feature is added I have a good idea of what was effected.
Roger J wrote:
the wole point of unittesting is to spend _less_ time writing test than you would spend manually testing it by clicking around in the application.
No matter how many unit tests I were to write, I still would need to test it by clicking around. I wouldn't feel comfortable just creating a build, checking that there are no testing failures, and then shipping the assemblies off to be packaged. Empirical testing, in my opinion, can never be replaced with automation. I suppose that if I were leading a dev team I'd require people to create unit tests, especially if I didn't know the team members. But for an app that I build without anyone else interfering, I still can't see it as a justifiable way to spend time. That's just me, I suppose. :josh: My WPF Blog[^]
-
I don't understand the hype surrounding TDD. Many people tell me that it's the greatest thing since sliced bread, but I've never used it and I get by just fine. According to the "Best Practices" commitee at my current client, TDD is really important. I have built them a large suite of applications, based on a huge business object framework completely rolled from scratch (around 30-35k lines), and there isn't a line of test code involved, except for Debug.Assert()s and checks for null. The apps work famously and there are hardly ever any bugs reported, maybe three or four minor tweaky issues have cropped up since I've been there (8 months). So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit. :josh: My WPF Blog[^]
Josh Smith wrote:
So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit.
That's because you did it backwards. You're supposed to write the tests first. Naturally, after writing 35K lines of code over 8 months, you don't want to go back to writing tests now. And quite frankly, I bet your architecture doesn't even readily support a TDD methodology, as TDD, while not driving architecture, is at least an influential consideration. And BTW, that's not meant as a criticism of your architecture, but just the reality, that writing tests after the fact can require changes to your code. And frankly, if you're code is working as well as you say, I wouldn't change it just to accomodate a TDD. Also, there's nothing wrong with good old fashioned asserts and null tests. Frankly, even with TDD, these should still be in your code, as part of TDD is to test how your code handles failures, not just the successes. (Would that we could test people the same way!) On the other hand, if your client wants to move forward with your BOF, there's some good business sense in writing tests now, so that as the BOF is enhanced, modified, whatever, your client has a suite of regression tests they can perform. And that's the real business case for TDD, IMO. (ah, BOF, TDD, IMO, BTW, where's my propeller beanie?) Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-- modified at 13:31 Sunday 16th July, 2006
-
I don't understand the hype surrounding TDD. Many people tell me that it's the greatest thing since sliced bread, but I've never used it and I get by just fine. According to the "Best Practices" commitee at my current client, TDD is really important. I have built them a large suite of applications, based on a huge business object framework completely rolled from scratch (around 30-35k lines), and there isn't a line of test code involved, except for Debug.Assert()s and checks for null. The apps work famously and there are hardly ever any bugs reported, maybe three or four minor tweaky issues have cropped up since I've been there (8 months). So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit. :josh: My WPF Blog[^]
Josh Smith wrote:
I just don't see the benefit.
It's only a benefit if you can test against something, eg some algorhithm.**
xacc.ide-0.2.0 preview - Now in 100% C# goodness
**
-
I don't understand the hype surrounding TDD. Many people tell me that it's the greatest thing since sliced bread, but I've never used it and I get by just fine. According to the "Best Practices" commitee at my current client, TDD is really important. I have built them a large suite of applications, based on a huge business object framework completely rolled from scratch (around 30-35k lines), and there isn't a line of test code involved, except for Debug.Assert()s and checks for null. The apps work famously and there are hardly ever any bugs reported, maybe three or four minor tweaky issues have cropped up since I've been there (8 months). So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit. :josh: My WPF Blog[^]
i am impressed to see so much code working so well. not because this is impossible to do, but because so many people don't seem to do it (mutters darkly about trainee programmers i have had to clean up behind) so with this in mind, i am curious. is the code quality the result of a solid up front design, or of lots of "can i brake this" testing by hand as you have gone along? or do you have some other secret? :) i find the *idea* of unit tests for my code interesting, but most information i have encountered on the subject seems aimed at C#, and does not look well suited to GUI heavy C++ code, so i have never got past the vague interest stage *shrug* so i just try to be very careful when writing my code, and give it a good hammering, before sending it off to be tested, which seems to work quite well for me personally, and the general quality is very good. zen is the art of being at one with the two'ness
-
Josh Smith wrote:
So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit.
That's because you did it backwards. You're supposed to write the tests first. Naturally, after writing 35K lines of code over 8 months, you don't want to go back to writing tests now. And quite frankly, I bet your architecture doesn't even readily support a TDD methodology, as TDD, while not driving architecture, is at least an influential consideration. And BTW, that's not meant as a criticism of your architecture, but just the reality, that writing tests after the fact can require changes to your code. And frankly, if you're code is working as well as you say, I wouldn't change it just to accomodate a TDD. Also, there's nothing wrong with good old fashioned asserts and null tests. Frankly, even with TDD, these should still be in your code, as part of TDD is to test how your code handles failures, not just the successes. (Would that we could test people the same way!) On the other hand, if your client wants to move forward with your BOF, there's some good business sense in writing tests now, so that as the BOF is enhanced, modified, whatever, your client has a suite of regression tests they can perform. And that's the real business case for TDD, IMO. (ah, BOF, TDD, IMO, BTW, where's my propeller beanie?) Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-- modified at 13:31 Sunday 16th July, 2006
I suppose that I would need to see a well designed test suite to be convinced that it proffers advantages above and beyond asserts and null checks. I've never worked in a TDD environment before, so I've never seen the benefits first hand.
Marc Clifton wrote:
On the other hand, if your client wants to move forward with your BOF, there's some good business sense in writing tests now, so that as the BOF is enhanced, modified, whatever, your client has a suite of regression tests they can perform.
Eek! Don't give them any ideas!! :~
Marc Clifton wrote:
(ah, BOF, TDD, IMO, BTW, where's my propeller beanie?)
:laugh: WMPB? (Where's my propeller beanie?) YPYPBNTYLSOPP! (You put your propeller beanie next to your lifetime supply of pocket protectors!) :josh: My WPF Blog[^]
-
I don't understand the hype surrounding TDD. Many people tell me that it's the greatest thing since sliced bread, but I've never used it and I get by just fine. According to the "Best Practices" commitee at my current client, TDD is really important. I have built them a large suite of applications, based on a huge business object framework completely rolled from scratch (around 30-35k lines), and there isn't a line of test code involved, except for Debug.Assert()s and checks for null. The apps work famously and there are hardly ever any bugs reported, maybe three or four minor tweaky issues have cropped up since I've been there (8 months). So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit. :josh: My WPF Blog[^]
Clients that know about it like it because it aids in ensuring that only that which they need gets built. Its an effective armor against gold plating. It works best when you build the test stubs first and then code to satisfy their requirements. By the time you've satisfied the test, your done. So really your not spending all your time writing tests, your using the tests to guide your development and spend all your time writing the app. In your case you might have been able to trim 5k lines of code and maybe a month of coding. But.. yer mileage may vary. This statement is false.
-
i am impressed to see so much code working so well. not because this is impossible to do, but because so many people don't seem to do it (mutters darkly about trainee programmers i have had to clean up behind) so with this in mind, i am curious. is the code quality the result of a solid up front design, or of lots of "can i brake this" testing by hand as you have gone along? or do you have some other secret? :) i find the *idea* of unit tests for my code interesting, but most information i have encountered on the subject seems aimed at C#, and does not look well suited to GUI heavy C++ code, so i have never got past the vague interest stage *shrug* so i just try to be very careful when writing my code, and give it a good hammering, before sending it off to be tested, which seems to work quite well for me personally, and the general quality is very good. zen is the art of being at one with the two'ness
feline_dracoform wrote:
i am impressed to see so much code working so well.
So is my client. :->
feline_dracoform wrote:
not because this is impossible to do, but because so many people don't seem to do it (mutters darkly about trainee programmers i have had to clean up behind)
I'm not a trainee programmer, I'm a senior consultant. No, I'm not boasting or implying that titles matter, I'm just saying that you get what you pay for.
feline_dracoform wrote:
is the code quality the result of a solid up front design, or of lots of "can i brake this" testing by hand as you have gone along? or do you have some other secret?
Once again, not to boast or blow my own bubble, but I'm really good at creating software. I love it, I do it in my free time, I read about it before falling asleep, I read about it on my commute, I talk about it with strangers online, etc. There's no black magic or secret tricks, just dedication and experience. It doesn't hurt that I don't have to work with others. I designed the entire system from the ground up, I wrote all the code, I chose the design patterns to use, I chose the naming conventions, and every other detail was under my control. That's the best way to get quality software: give one (possibly two) dedicated expert the freedom to create it as he/she sees fit and then leave them alone until it's done. Throwing a crappy dev into the mix is like adding poison to the punch. :josh: My WPF Blog[^]
-
Clients that know about it like it because it aids in ensuring that only that which they need gets built. Its an effective armor against gold plating. It works best when you build the test stubs first and then code to satisfy their requirements. By the time you've satisfied the test, your done. So really your not spending all your time writing tests, your using the tests to guide your development and spend all your time writing the app. In your case you might have been able to trim 5k lines of code and maybe a month of coding. But.. yer mileage may vary. This statement is false.
Chris S Kaiser wrote:
In your case you might have been able to trim 5k lines of code and maybe a month of coding.
I doubt my consulting firm would like that very much! :-D :josh: My WPF Blog[^]
-
Roger J wrote:
"you" in this case is you and your QA team and everyone else that is responsible for delivering a solid app.
For better or worse, I am the only person involved with creating this application suite. That makes testing it easier, in some ways, because when a feature is added I have a good idea of what was effected.
Roger J wrote:
the wole point of unittesting is to spend _less_ time writing test than you would spend manually testing it by clicking around in the application.
No matter how many unit tests I were to write, I still would need to test it by clicking around. I wouldn't feel comfortable just creating a build, checking that there are no testing failures, and then shipping the assemblies off to be packaged. Empirical testing, in my opinion, can never be replaced with automation. I suppose that if I were leading a dev team I'd require people to create unit tests, especially if I didn't know the team members. But for an app that I build without anyone else interfering, I still can't see it as a justifiable way to spend time. That's just me, I suppose. :josh: My WPF Blog[^]
Yeah, I don't think its meant to replace Empirical testing but to enhance it. Its your first line of defense when refactoring. As said before you can use it to at least ensure that nothing major was broken. But I find that it helps to start with it. Plugging it in after the fact could be monumentous. This statement is false.
-
Josh Smith wrote:
So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit.
That's because you did it backwards. You're supposed to write the tests first. Naturally, after writing 35K lines of code over 8 months, you don't want to go back to writing tests now. And quite frankly, I bet your architecture doesn't even readily support a TDD methodology, as TDD, while not driving architecture, is at least an influential consideration. And BTW, that's not meant as a criticism of your architecture, but just the reality, that writing tests after the fact can require changes to your code. And frankly, if you're code is working as well as you say, I wouldn't change it just to accomodate a TDD. Also, there's nothing wrong with good old fashioned asserts and null tests. Frankly, even with TDD, these should still be in your code, as part of TDD is to test how your code handles failures, not just the successes. (Would that we could test people the same way!) On the other hand, if your client wants to move forward with your BOF, there's some good business sense in writing tests now, so that as the BOF is enhanced, modified, whatever, your client has a suite of regression tests they can perform. And that's the real business case for TDD, IMO. (ah, BOF, TDD, IMO, BTW, where's my propeller beanie?) Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-- modified at 13:31 Sunday 16th July, 2006
Marc Clifton wrote:
is to test how your code handles failures, not just the successes. (Would that we could test people the same way!)
Don't know what your spiritualism extends to, but its been said that when your in partnership with the spiritual tutors, your life gets harder not easier, as we are measured by how we handle failure and not success. That ol' divine providence... myth? ;) Although I prefer the Coyote reference of the trickster keeping us on our spiritual toes. This statement is false.
-
Chris S Kaiser wrote:
In your case you might have been able to trim 5k lines of code and maybe a month of coding.
I doubt my consulting firm would like that very much! :-D :josh: My WPF Blog[^]
Dunno.. I'm finding that there never is any end to the work needed. I'm starting to like the idea of building something and then selling it off for someone else to maintain. As agile as I try to remain, enhancement requests are always causing me to refactor under the gun.. although that's more of an artificial deadline thing. This statement is false.
-
I don't understand the hype surrounding TDD. Many people tell me that it's the greatest thing since sliced bread, but I've never used it and I get by just fine. According to the "Best Practices" commitee at my current client, TDD is really important. I have built them a large suite of applications, based on a huge business object framework completely rolled from scratch (around 30-35k lines), and there isn't a line of test code involved, except for Debug.Assert()s and checks for null. The apps work famously and there are hardly ever any bugs reported, maybe three or four minor tweaky issues have cropped up since I've been there (8 months). So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit. :josh: My WPF Blog[^]
I suspect that like a lot of things in the programming world it's just another way to manage large projects with large numbers of programmers. A lot of theories and practices you hear about for development just don't scale down at all to small shops with smaller teams or projects. Take it and anything else with a grain of salt and steal only the bits that help and drop the rest.
-
I suspect that like a lot of things in the programming world it's just another way to manage large projects with large numbers of programmers. A lot of theories and practices you hear about for development just don't scale down at all to small shops with smaller teams or projects. Take it and anything else with a grain of salt and steal only the bits that help and drop the rest.
John Cardinal wrote:
I suspect that like a lot of things in the programming world it's just another way to manage large projects with large numbers of programmers.
Ok, now we're getting somewhere! That makes a lot of sense to me. For a project which is large enough to require a large team, I can see how unit tests would provide accountability.
John Cardinal wrote:
Take it and anything else with a grain of salt and steal only the bits that help and drop the rest.
Yeah, good advice. :-D :josh: My WPF Blog[^]
-
I don't understand the hype surrounding TDD. Many people tell me that it's the greatest thing since sliced bread, but I've never used it and I get by just fine. According to the "Best Practices" commitee at my current client, TDD is really important. I have built them a large suite of applications, based on a huge business object framework completely rolled from scratch (around 30-35k lines), and there isn't a line of test code involved, except for Debug.Assert()s and checks for null. The apps work famously and there are hardly ever any bugs reported, maybe three or four minor tweaky issues have cropped up since I've been there (8 months). So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit. :josh: My WPF Blog[^]
Your attitude reflects mine a few months ago. I was very skeptical, especially with all the surrounding hype. But after using it now for several months, whilst getting exposed to mock objects and the like, I've found TDD is awesome for several reasons. For one, you get more stable, more easily refactor-able code. This is because you are certain each function behaves exactly how you expect it to behave. Another great that is you can fix a bug, then write a test for it to ensure the bug never happens again. Moreover, you can write a feature or bug fix, then test it completely from code. Forget the whole code/run/restart dance; you can test a feature completely by running tests. This not only saves time (you don't have to wait for your big rich client to startup, connect to your server, then try out the new functionality), but it also is more comprehensive, covering things that would be difficult to test, or so rare occurring that one would rarely run into it in the real world. Tests can be run quickly and can be run on any developer's machine, thus, if you refactor your code, you can run the test to tell you if you broke anything during the refactor. Finally, tests are like live documentation; a test like ShouldReturnNonNullStringOnValidInput is self-explanatory. If a developer comes along and modifies that function, your test will point it out immediately. My only complaint about TDD is it requires more time invested into writing code. However, the time invested is actually time saved, as you don't have as many bugs and you don't have to do that code/debug/rerun drudgery.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Goof around music jam with my brothers (with video) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
-
Your attitude reflects mine a few months ago. I was very skeptical, especially with all the surrounding hype. But after using it now for several months, whilst getting exposed to mock objects and the like, I've found TDD is awesome for several reasons. For one, you get more stable, more easily refactor-able code. This is because you are certain each function behaves exactly how you expect it to behave. Another great that is you can fix a bug, then write a test for it to ensure the bug never happens again. Moreover, you can write a feature or bug fix, then test it completely from code. Forget the whole code/run/restart dance; you can test a feature completely by running tests. This not only saves time (you don't have to wait for your big rich client to startup, connect to your server, then try out the new functionality), but it also is more comprehensive, covering things that would be difficult to test, or so rare occurring that one would rarely run into it in the real world. Tests can be run quickly and can be run on any developer's machine, thus, if you refactor your code, you can run the test to tell you if you broke anything during the refactor. Finally, tests are like live documentation; a test like ShouldReturnNonNullStringOnValidInput is self-explanatory. If a developer comes along and modifies that function, your test will point it out immediately. My only complaint about TDD is it requires more time invested into writing code. However, the time invested is actually time saved, as you don't have as many bugs and you don't have to do that code/debug/rerun drudgery.
Tech, life, family, faith: Give me a visit. I'm currently blogging about: Goof around music jam with my brothers (with video) The apostle Paul, modernly speaking: Epistles of Paul Judah Himango
Judah Himango wrote:
This not only saves time (you don't have to wait for your big rich client to startup, connect to your server, then try out the new functionality), but it also is more comprehensive, covering things that would be difficult to test, or so rare occurring that one would rarely run into it in the real world.
this comment strikes me, since a lot of my programming work can be described as a thick client. i read a small amount about TDD for a program that connects to a database, and was left with the impression that you had to setup a fake database for the tests, etc. i just have no "world view" of how to approach TDD *shrug* from your experience, or if anyone else has any experience, let me explain one area of code i develop and maintain. we have data files (flat files, complex format) and i have a set of code to render these data files as HTML, to show the user. there is a specification, with pages of rules, describing how and when data must be placed into the HTML X| its a rather nasty specification to work with. the rendering code is nice and modular, but complex. most of the bits are very simple (insert a bold word) but a few are complex (parse the data file into logical blocks depending on its format). given the input is a record from a database and the output is a piece of HTML i get the feeling TDD is going to be a set of input files and a set of "valid outputs", and basically a long list of "input A gives output B" tests, which will be a pile of work to setup. *wonders* as i am thinking this through i may be making progress in understanding this. would a TDD approach be a series of input files, ranging from very basic to very complex, so you start by satisfying the very basic tests first, slowly working up to the complex tests? or am i still missing the core idea at work here? zen is the art of being at one with the two'ness
-
I don't understand the hype surrounding TDD. Many people tell me that it's the greatest thing since sliced bread, but I've never used it and I get by just fine. According to the "Best Practices" commitee at my current client, TDD is really important. I have built them a large suite of applications, based on a huge business object framework completely rolled from scratch (around 30-35k lines), and there isn't a line of test code involved, except for Debug.Assert()s and checks for null. The apps work famously and there are hardly ever any bugs reported, maybe three or four minor tweaky issues have cropped up since I've been there (8 months). So, why on Earth should I spend a large amount of my time building tests? I just don't see the benefit. :josh: My WPF Blog[^]
You never see the real advantage to it until you get a feature request that requires you to take the app appart and put it together again to do it right. With a large suite of tests you can be much more fearless doing things the right way even though they are high risk rather then slapping in a couple of hacks to get through this round of updates. It also defends against the ravages of time. If you have to make a change a year from now after you've been using xyz control library and the latest and greatest development techniques. The test library saves you from inadvertently breaking everything you've forgotten about in the meantime. [edit] Another advantage is coverage. When I worked at Dell, the only way we could get in the sub-thousand ASP errors per day were to write brutal automated tests that randomly clicked arond the site while entering random data in all the forms. All all that to get in the 0.0x% error rate. When you serve millions of pages a day, you get several one in a million events a day. [/edit]
I can imagine the sinking feeling one would have after ordering my book, only to find a laughably ridiculous theory with demented logic once the book arrives - Mark McCutcheon
-- modified at 15:46 Sunday 16th July, 2006
-
feline_dracoform wrote:
i am impressed to see so much code working so well.
So is my client. :->
feline_dracoform wrote:
not because this is impossible to do, but because so many people don't seem to do it (mutters darkly about trainee programmers i have had to clean up behind)
I'm not a trainee programmer, I'm a senior consultant. No, I'm not boasting or implying that titles matter, I'm just saying that you get what you pay for.
feline_dracoform wrote:
is the code quality the result of a solid up front design, or of lots of "can i brake this" testing by hand as you have gone along? or do you have some other secret?
Once again, not to boast or blow my own bubble, but I'm really good at creating software. I love it, I do it in my free time, I read about it before falling asleep, I read about it on my commute, I talk about it with strangers online, etc. There's no black magic or secret tricks, just dedication and experience. It doesn't hurt that I don't have to work with others. I designed the entire system from the ground up, I wrote all the code, I chose the design patterns to use, I chose the naming conventions, and every other detail was under my control. That's the best way to get quality software: give one (possibly two) dedicated expert the freedom to create it as he/she sees fit and then leave them alone until it's done. Throwing a crappy dev into the mix is like adding poison to the punch. :josh: My WPF Blog[^]
Josh Smith wrote:
It doesn't hurt that I don't have to work with others. I designed the entire system from the ground up, I wrote all the code, I chose the design patterns to use, I chose the naming conventions, and every other detail was under my control. That's the best way to get quality software: give one (possibly two) dedicated expert the freedom to create it as he/she sees fit and then leave them alone until it's done. Throwing a crappy dev into the mix is like adding poison to the punch.
I'm doing that on a BOF application for a client of mine, and, as much as I wish I could disagree, I can't. I'm really glad I'm the only architect on this project and the only developer. If I were to add another developer, I would probably spend all my time looking over his shoulder to make sure he/she does things right (right being defined as "my kind of right"). Conversely, I've been involved in other projects where I am ashamed to even have my name associated with the project as the code is so gawdawful. And nowadays, it seems my name carries some weight, so it's all the more important that I'm careful as to how I implicitly end up endorsing someone else's fiasco. Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-
I suppose that I would need to see a well designed test suite to be convinced that it proffers advantages above and beyond asserts and null checks. I've never worked in a TDD environment before, so I've never seen the benefits first hand.
Marc Clifton wrote:
On the other hand, if your client wants to move forward with your BOF, there's some good business sense in writing tests now, so that as the BOF is enhanced, modified, whatever, your client has a suite of regression tests they can perform.
Eek! Don't give them any ideas!! :~
Marc Clifton wrote:
(ah, BOF, TDD, IMO, BTW, where's my propeller beanie?)
:laugh: WMPB? (Where's my propeller beanie?) YPYPBNTYLSOPP! (You put your propeller beanie next to your lifetime supply of pocket protectors!) :josh: My WPF Blog[^]
Josh Smith wrote:
I suppose that I would need to see a well designed test suite to be convinced that it proffers advantages above and beyond asserts and null checks.
Well, some advice, if I may. Decouple the need for a "well designed test suite" from the advantages of TDD. Also, don't buy into TDD whole hog--it needs to meet your requirements, budget, timeframe, it needs to be part of the planning for the product lifecycle. Not being happy with nUnit, I wrote my own test framework. Am I happy with it? Mostly, but there's a few little nits that unfortunately would require pretty much a complete rewrite, argh (let me tell you about ApplicationDomain and marshalling across app domain boundaries and serializable classes one day). From my own experiences, I can tell you there is great pleasure in making a change to, say, my persistence service to add automatic client synchronization, and knowing when I'm done that I can rerun my unit tests to verify that all the other functionality is still working. I will say one thing though--I still can't write the test first. I have to write at least stubs for the actual code and then write the tests. It's because I do a lot of architecting when writing the code itself, as, ironically, I haven't found any decent code architecture/design tools--tools that don't hinder the creative process. Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow
-
Marc Clifton wrote:
is to test how your code handles failures, not just the successes. (Would that we could test people the same way!)
Don't know what your spiritualism extends to, but its been said that when your in partnership with the spiritual tutors, your life gets harder not easier, as we are measured by how we handle failure and not success. That ol' divine providence... myth? ;) Although I prefer the Coyote reference of the trickster keeping us on our spiritual toes. This statement is false.
Chris S Kaiser wrote:
but its been said that when your in partnership with the spiritual tutors, your life gets harder not easier, as we are measured by how we handle failure and not success.
Aye, I've heard that before. You bring up a good point, but I've discovered that "hard" is pretty relative. When I think my life is getting hard, I remember my best friend who's son died when he was 9. I think about farmers in Africa that are just trying to eek by an existence amid the ravishes of warlords. Etc. So, I just can't feel that, compartively speaking, my life has ever been hard. Marc Pensieve
Some people believe what the bible says. Literally. At least [with Wikipedia] you have the chance to correct the wiki -- Jörgen Sigvardsson
People are just notoriously impossible. --DavidCrow