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[^]
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
-
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
Marc Clifton wrote:
When I think my life is getting hard, I remember
Absolutely. When in college I used to take different math classes for fun. Mostly because they covered cool subjects like permutations, set theory and the like, well my lab partner was this guy who had brain surgery when he was younger, major brain surgery. Part of his skull was missing. And when hanging out with him, trying to measure the volume of a fountain, people would walk up and ask how he was doin, and he always said "Good". At that point he made it so at best I could only say "Not bad" cause it was never as bad as the struggle he faced. He's still one of my role models. This statement is false.
-
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'm on a team with a few people here, but I'm the only one working on the mobile side. So I get that experience there, while on the server side its shared, and while I won't bash the server code, its not bad, I really enjoy being the sole developer on the mobile side. Part of it for me is that I get to think how "I" think vs the standardized group think. Since we spend most of our time in the code, I wonder how many people realize that its a matter of thinking. That was vague, but this is the reason I can't code in VB. An old version is in VB that I still have to maintain, someone else's code, but everytime I work in it my brain hurts, not because I'm prejudice, but because I just can't think that way. This statement is false.
-
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
Sounds like a multiple staged approach. I would start with a test to parse the input files validating their format. So that part just validates the formatting. If you have an app that generates these files, you could plug the test in to validate the output before saving. Then I'd have another test that would validate the output given an input file that passed the first test but is feature complete. And really this is where it gets vague and complex. This might not be able to have an automated result. As it might be a visual test requiring the human involved with looking at how it appeals to the eye. I don't think its supposed to be the panacea of dev. But an excellent supplement and sanity check. 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 support your skepticism. The core of TDD is writing tests before you write the code. I've found this tends to lead to inferior code since the resulting code tends to be written to be easily tested, not to solve the problem of the larger system. The bigger problem with TDD is that it assumes you have correctly anticipated all the requirements of the code and how the code will actually be used. Having said this, do be careful not to throw the baby out with the bath water. While I reject the core notion of TDD--writing tests first--automated testing for modules is a VERY good practice. This allows you to add tests as failure modes become known and a good way to regress any changes you make to the code. (One problem in TDD is finding that a fundamental code change will greatly improve the application but will render the tests invalid as written. This WILL happen often. The temptation is to compromise the code so the tests either don't have to be rewritten or the rewrite is minimal. If you aren't careful, you end up creating an application that passes all the tests, but doesn't solve the customer's problem. As a developer, we may proclaim this simply won't happen, but tell that to the people writing your paychecks.) Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
I'm on a team with a few people here, but I'm the only one working on the mobile side. So I get that experience there, while on the server side its shared, and while I won't bash the server code, its not bad, I really enjoy being the sole developer on the mobile side. Part of it for me is that I get to think how "I" think vs the standardized group think. Since we spend most of our time in the code, I wonder how many people realize that its a matter of thinking. That was vague, but this is the reason I can't code in VB. An old version is in VB that I still have to maintain, someone else's code, but everytime I work in it my brain hurts, not because I'm prejudice, but because I just can't think that way. This statement is false.
Chris S Kaiser wrote:
but because I just can't think that way.
Exactly, and not just related to VB. I'm working with a client that is putting together a huge client-server system, and I simply cannot get my head around his architecture, nor his code. I don't think my brain is wired right. I understand things for about a day, and then they leak out and I'm left asking "why are we doing it this way?" and "what does this code do again?". Of course, it doesn't help that there are zero design documents, zero architectural diagrams (except the ones I've done), zero unit tests, and about .01% of the code is commented (and the reason it's even .01% is because of the code comments that I religiously put into the parts I've contributed in this latest round of rewrites). So maybe that explains why my brain feels like a sieve when I look at the code. 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
-
Chris S Kaiser wrote:
but because I just can't think that way.
Exactly, and not just related to VB. I'm working with a client that is putting together a huge client-server system, and I simply cannot get my head around his architecture, nor his code. I don't think my brain is wired right. I understand things for about a day, and then they leak out and I'm left asking "why are we doing it this way?" and "what does this code do again?". Of course, it doesn't help that there are zero design documents, zero architectural diagrams (except the ones I've done), zero unit tests, and about .01% of the code is commented (and the reason it's even .01% is because of the code comments that I religiously put into the parts I've contributed in this latest round of rewrites). So maybe that explains why my brain feels like a sieve when I look at the code. 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
That's funny. There are no comments in this code. Mostly because the manager doesn't believe in them. The theory was: If you don't understand the code from reading it you probably don't belong here. ;) Which has its merits I guess. But looking at some of my code, I'm left wondering WTF I was thinking. I've commented some of it, but not enough. The other one I love alot is lacking requirements. The date gets set, and then the requirements get filled in. And they wonder why that impacts the release date. I'm being too nitpicky when I ask for complete definitions. But then I share in the heat when its late. Heh heh.. I better duck, my manager might be reading. ;) Funny, I'm on contract but he's still my boss. The lacking comments is my fault though, I just blasted through the code to get it released, and now I'm paying for it. This statement is false.
-
That's funny. There are no comments in this code. Mostly because the manager doesn't believe in them. The theory was: If you don't understand the code from reading it you probably don't belong here. ;) Which has its merits I guess. But looking at some of my code, I'm left wondering WTF I was thinking. I've commented some of it, but not enough. The other one I love alot is lacking requirements. The date gets set, and then the requirements get filled in. And they wonder why that impacts the release date. I'm being too nitpicky when I ask for complete definitions. But then I share in the heat when its late. Heh heh.. I better duck, my manager might be reading. ;) Funny, I'm on contract but he's still my boss. The lacking comments is my fault though, I just blasted through the code to get it released, and now I'm paying for it. This statement is false.
Chris S Kaiser wrote:
I just blasted through the code to get it released, and now I'm paying for it.
I've been there. :( I try to take the time nowadays, but it's still not easy.
Chris S Kaiser wrote:
Mostly because the manager doesn't believe in them. The theory was: If you don't understand the code from reading it you probably don't belong here.
Lovely. It's not just the code itself, but the thinking behind the code, the understanding of the overall algorithm, that's what I try to document. Why am I doing it this way vs What is it doing. I must say though, looking at the .NET framework code with Reflector, without the benefit of comments, I can easily figure out what it's doing because it's so well written. You don't have functions that go on for hundreds of lines. Anything that does something is usually encapsulated in a method. The resulting high level code is basically just logic and loops that surrounds method calls. The low level methods themselves are so small, it's easy to understand what they do. Impressive. 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
-
Chris S Kaiser wrote:
I just blasted through the code to get it released, and now I'm paying for it.
I've been there. :( I try to take the time nowadays, but it's still not easy.
Chris S Kaiser wrote:
Mostly because the manager doesn't believe in them. The theory was: If you don't understand the code from reading it you probably don't belong here.
Lovely. It's not just the code itself, but the thinking behind the code, the understanding of the overall algorithm, that's what I try to document. Why am I doing it this way vs What is it doing. I must say though, looking at the .NET framework code with Reflector, without the benefit of comments, I can easily figure out what it's doing because it's so well written. You don't have functions that go on for hundreds of lines. Anything that does something is usually encapsulated in a method. The resulting high level code is basically just logic and loops that surrounds method calls. The low level methods themselves are so small, it's easy to understand what they do. Impressive. 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:
It's not just the code itself, but the thinking behind the code, the understanding of the overall algorithm, that's what I try to document.
I do try to limit my comments to this type. The code self documents to a degree. But then I love to engineer wondrous works. :-> Which sometimes leaves myself baffled. Nice dynamic data driven solutions where the usage at the top level is as you describe, usually just method calls, and nothing more than 10 lines, but in the framework... :doh: the price is paid. So in that regard I like the tradeoff, I just need to take the time. Its amazing to me that my brain won't retain its own spewage sometimes.
Marc Clifton wrote:
looking at the .NET framework code with Reflector,
Marc Clifton wrote:
Impressive.
Yep, looks like its time to give this app a whirl. This statement is false.
-
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:
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.
I always thought unit testing was for testing methods of a single class? How do you test features/bugs that span multiple modules? Do you still use NUnit? Regards Senthil _____________________________ My Blog | My Articles | My Flickr | WinMacro
-
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[^]
A bit off topic, but...
Josh Smith wrote:
I have built them a large suite of applications, based on a huge business object framework completely rolled from scratch (around 30-35k lines)
That's all? Just 35K lines? The project we just EOL'd was over 675,000 lines, and there were only two programmers working on it. Our current project is over 175,000 lines, and it's only six months in development with one programmer working on it (me). Then there's the project where we're writing a very small piece of a much larger system, and we have over 300,000 lines invested in that (again, just two programmers). 35K lines? I'm sorry, but I'm laughing my ass off... :)
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 -
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:
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.
We recently had a break out discussion at our local user group over the topic of TDD, and this was one of things covered. The one thing I try to keep in mind is: "Describe what it needs to do, not how it needs to do it". You really have to change the way you think about writing code, if you can't do that, there will be major hurdles you will have to deal with later on. My 2 cents. :-)
- Nick Parker Microsoft MVP - Visual C#
My Blog | My Articles -
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
feline_dracoform wrote:
was left with the impression that you had to setup a fake database for the tests, etc.
It depends. Here's how it goes: you write a test for a function. Then you realize that your function calls into something you don't want to test; maybe it calls into your data layer, or maybe it shows a dialog, etc. Since you're just testing this function, you want the test to be small and precise; you don't need to test your whole data layer; in fact, you want your test to execute instantly, you don't want it to even connect to your data layer. So here's where the mock objects come in; they let you mock your data layer or other resource you don't want this small test to encompass. Let's take a real example. You have a function called UpdateRecord that takes a patient record, changes the patient's last check-in time, and saves it to your data layer (which then saves it to the database or some other persistent storage).
public void UpdateRecord(Patient patientToUpdate)
{
patientToUpdate.LastCheckInTime = DateTime.Now;
dataLayer.SavePatient(patientToUpdate);
}To really test this function, you'll want to verify that the date was set correctly and that it gets saved back to the data layer. How in the world can you do this, you might wonder. :) You can do this by refactoring your code to make it more modular and unit-testable; basically, making the function be more of a "unit" by itself, rather than relying on internals and variables. So let's first refactor the function so that we supply the date to the function, so that we can verify it's getting set correctly.
public void UpdateRecord(Patient patientToUpdate, DateTime updateTime)
{
patientToUpdate.LastCheckInTime = updateTime;
dataLayer.SavePatient(patientToUpdate);
}With that, we can now write a simple test that verifies the patient's LastCheckInTime is set correctly.
[Test] // The Test attribute is an attribute in an NUnit assembly that lets unit testing frameworks know this function is a test function
public void UpdateRecordShouldSetCheckinTime()
{
Patient patient = new Patient();
DateTime checkinTime = DateTime.Now();
myFoo.UpdateRecord(patient, checkinTime);// Assert class is a class in an NUnit assembly that allows a test to pass or fail based on some condition. Assert.AreEqual(checkinTime, patient.LastCheckinTime, "The UpdateRecord method didn't set the last checkin time of the patient.");}
Now, we also nee
