TDD : DO I reallly needs to learn it ?
-
excuse my ignorance but do you apply TDD to data as well? do lets say I have a depreciation class that does financial depreciation by loading up some data and calling a stored procedure. How would you use TDD in this scenario ? Do you have to set up your data before every test and then check that the correct depreciation entries were made in the database? We have heard that TDD is not really useful in UI, I guess what I'm asking is how well does TDD work with checking: a) the source of the data b) the processing of the data c) the resulting data. So many of our apps nowdays are heavily dependant on databases does TDD suit this scenario?
I don't consider data to be separate from the program with respect to testing! A program can fail both of incorrect implementation or from bad data, but in the latter case, there should be a specified error behaviour, and a test case covering it. That means that a single function shouldn't be covered by just one test case, but several ones that verify the expected behaviour for both good and bad cases. Each test case therefore does include specific data. I realize that just setting up such test data sets could be very difficult in some cases - it sure is in our application and I've yet to find a good method. With respect to databases I'd like to add that articles on testing like to mention the option to replace complex parts of your system (such as databases) with mock objects: e. g. instead of connecting to an actual database, you create an object that implements the same interface, but all it does is just deliver the data you require for a specific test. Of course that implies that you *have* an interface to start with, and a factory pattern to create the real object - else you would need to change the code that accesses it, i. e. the code you're supposed to test, and that would be beside the point.
-
I used a small project a few years ago to try out TDD. Pros: * I learned a lot about writing useful unit tests, not just the "does it handle a bad argument in the method" garbage most unit tests seem to do. * It got me thinking about architecture much earlier * It got me thinking about functionality and it was neat to have stubs for various classes and methods, and as the stubs got filled in with actual code, watching the little red lights turn green. * I enjoyed thinking about things from a different perspective. Cons: * There's a disconnect between developing the test, no matter how well you think you've designed the architecture, and actually implementation when you realize you need to tweak the architecture. * The tests became a liability--they frequently needed updating as the architecture changed * As coders, we think we can test code. But most of what I ended up needing tests for was UI behavior. What's the best way to make sure a method doesn't get called? To disable the button or combobox so the user doesn't do something prematurely! Writing test code for UI's is not the same thing as writing tests against code. Big fail in the TDD concept, in my opinion. * Effectively doubles the time it takes to put out a project. No, it doesn't save time. No, it doesn't necessarily make the code more robust. You can easily end up with more test code than actual application code. * Set up for complex projects is, well, complex. Setting up initial data, etc. * Without a mocking framework, TDD is sort of useless for anything but trivial tests. You need a mocking framework to spoof the DB connection, the communication channels, the UI, etc. So, ultimately, I came to the conclusion that it's a nice idea, it's a useful tool, but use it judiciously. Like anything else! Marc
My Blog
An Agile walk on the wild side with Relationship Oriented ProgrammingAs someone who started trying TDD last Feb but really hit it hard on a project a few months ago, here's my takeaway regarding some of the cons. UI testing is getting more and less of a problem. Frameworks like MVC are making it so that if things are written well there should be very little view logic in your controller code. I'm incredibly grateful to no longer have to see code like (if data = 37 then control.hide()) or something similar. On the other hand, so much logic is happening in Javascript now that unless you're using something like QUnit (and enforcing it among the teams) you're back to square one. I'd argue TDD does save time, but that time is manifested as time you didn't have to spend researching, finding, fixing, testing, and deploying a bug. We've just started TDD on a project and I've seen what happens when tests are run and I've seen the case where we've chased a bug only to be frustrated that had the developer who changed the feature run the tests (or if the automation had run it...different problem heh) we'd have saved a few hours. TDD certainly increases your dev time though, no question there. Speaking from a .NET perspective, with things like RhinoMocks and Moq, not having a mocking framework really shouldn't be an excuse. And if you're doing IoC you have Ninject, StructureMap, etc., so building apps in such a way that you can use a mocked db layer or a real one should also be fairly simple. My two cents.
-
I don't consider data to be separate from the program with respect to testing! A program can fail both of incorrect implementation or from bad data, but in the latter case, there should be a specified error behaviour, and a test case covering it. That means that a single function shouldn't be covered by just one test case, but several ones that verify the expected behaviour for both good and bad cases. Each test case therefore does include specific data. I realize that just setting up such test data sets could be very difficult in some cases - it sure is in our application and I've yet to find a good method. With respect to databases I'd like to add that articles on testing like to mention the option to replace complex parts of your system (such as databases) with mock objects: e. g. instead of connecting to an actual database, you create an object that implements the same interface, but all it does is just deliver the data you require for a specific test. Of course that implies that you *have* an interface to start with, and a factory pattern to create the real object - else you would need to change the code that accesses it, i. e. the code you're supposed to test, and that would be beside the point.
Your reply makes sense, I find that most of our code "fails" because it encounters some data that is incorrectly configured and it then behaves in a way that the user is not expecting. The data was incorrectly configured by the user. To test multiple scenarios of configurations you would need to have multiple databases, alternatively, write a test script that prepares data then tests against that data. It all seems like an inordinate amount of work, do people really do this? I suppose thats why for the past 20 years we have let our users do the testing!
-
Your reply makes sense, I find that most of our code "fails" because it encounters some data that is incorrectly configured and it then behaves in a way that the user is not expecting. The data was incorrectly configured by the user. To test multiple scenarios of configurations you would need to have multiple databases, alternatively, write a test script that prepares data then tests against that data. It all seems like an inordinate amount of work, do people really do this? I suppose thats why for the past 20 years we have let our users do the testing!
Technically, yes, you'd have to provide test cases for everything that could go wrong, and that would indeed cost a lot of effort. A compromise would be to just provide one or a few cases of bad data, and only add more cases when you actually encounter a specific case that wasn't covered. It would prevent you from creating dozens of bad cases that in praxis never reeally happens. You'd still be able to run regression tests that way, i. e. when you fix a new bug, by always adding a test case for it you can make sure that the tests for already fixed bugs still pass. In the end it's you who must weigh the benefits of testing more against the effort it takes to produce these tests.
-
What is TTD actually? I never heard of it..
The general software design process looks roughly like this: 1. gather requirements 2. write use cases 3. implement them 4. write tests 5. test against the requirements In TDD it's more like 1. gather requirements 2. write test cases 3. implement them 4. write use cases 5. implement those 5.a) continually test the use case implementation using the already implemented tests Technically it shouldn't be all that different, but in praxis, tests are often written by the developers and tend to cover only the functionality that they have implemented, rather than the requirements that are supposed to be met. That only works if the use cases really fully cover the requirements, and the implementation really fully covers the use cases - and both are sometimes hard to verify. In TDD the test are written beforehand, the only information you can base them on are the requirements, so you're forced to implement that. Even if you lose information while writing and then implementing use cases, you'll catch that in testing. At least that is my understanding - you may want to check out wikipedia or other sources for a more in-depth explanation.
-
wout de zeeuw wrote:
But suppose you have 4000 complex features, and each release you need to guarantee that all of these work, and every week you want to release a new version with a couple of new features
It would be fascinating to read something that would explain how TDD would uniquely contribute to, or be essential to, the solution scenario you describe above ... compared with other so-called "development methodologies." best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
Wout hit it right on the head, IMHO. TDD's major value is in reduced cost of maintainability. If it's a ship it and forget it project, I've not found the overhead to be worthwhile. Conversely, if you are dealing with code you'll be enhancing, tweaking, and growing over months and years, the efficiency gains in pinpointing problematic code rapidly outweighs the overhead of writing the code.
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
I recall someone on gamedev once stated he finds books unnecessary as he taught all(!) software solutions to himself without any help. You might agree that this is likely a limited view angle. Trying new things is rarely the fastest way forward in my experience, but it might give you new valuable perspectives, even on things you already knew.
-
excuse my ignorance but do you apply TDD to data as well? do lets say I have a depreciation class that does financial depreciation by loading up some data and calling a stored procedure. How would you use TDD in this scenario ? Do you have to set up your data before every test and then check that the correct depreciation entries were made in the database? We have heard that TDD is not really useful in UI, I guess what I'm asking is how well does TDD work with checking: a) the source of the data b) the processing of the data c) the resulting data. So many of our apps nowdays are heavily dependant on databases does TDD suit this scenario?
Preface: I have a post earlier that makes a distinction between xUnit test frameworks, and the TDD process, so I won't repeat that info. They are two distinct parts that compliment each other nicely. One thing to keep in mind, is this all deals with "unit" testing. Which should be each distinct object, or global function that you create. However, it is possible to scale it up to integration and system level testing. As stated, it does not work well for UI testing. Now to your questions:
jasperp wrote:
do you apply TDD to data as well
Yes
jasperp wrote:
Do you have to set up your data before every test and then check that the correct depreciation entries were made in the database?
Yes
jasperp wrote:
I guess what I'm asking is how well does TDD work with checking: a) the source of the data b) the processing of the data c) the resulting data.
These are actually 3 different parts of the app to consider. a) The source of the data does not matter to the object that is processing the data, b) it only matters that the data is input properly, therefore this will be the System-Under-Test (SUT). c) This only matters in the sense that it becomes the verification data.
jasperp wrote:
So many of our apps nowdays are heavily dependant on databases does TDD suit this scenario?
This is the perfect scenario to use xUnit tests. You don't actually want to connect to a real-database when you are running your unit-tests. You want your tests to run quickly, and verify that your object is performing the proper actions. Generally this is done by creating stub objects to fill in for the databases, network connections, file access and so on. If you can isolate your objects with these unit-tests, then you create a much more flexible system with less dependencies. Look up blogs by Kent Beck and Michael Featherly. They have written some of the books that I have found very useful, and can provide more clarity that I can put in this forum entry.
All of my software is powered by a single Watt.
-
Wout hit it right on the head, IMHO. TDD's major value is in reduced cost of maintainability. If it's a ship it and forget it project, I've not found the overhead to be worthwhile. Conversely, if you are dealing with code you'll be enhancing, tweaking, and growing over months and years, the efficiency gains in pinpointing problematic code rapidly outweighs the overhead of writing the code.
If I ever have to again inherit code that I must enhance and maintain I would definitely use a TDD approach.
-
wout de zeeuw wrote:
But suppose you have 4000 complex features, and each release you need to guarantee that all of these work, and every week you want to release a new version with a couple of new features
It would be fascinating to read something that would explain how TDD would uniquely contribute to, or be essential to, the solution scenario you describe above ... compared with other so-called "development methodologies." best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
I like the TDD methodology. I dont have too much experience with many others related to unit-testing. TDD does not have to be followed to still have unit-tests. However, one of the other posters made a good point. When you write the tests up front, you are integrating the testing with thinking for design and implementation. When you write the tests as an after thought, it becomes mundane, and feels like an unnecessary chore. * The longer the code will be in use, the greater the benefit from building a test framework around the source. * Each time a defect is discovered, first write a test to detect the defect, then add the fix. If you maintain the tests as well as the code, you should never see the same defect twice. * It allows new developers to the project to understand the system faster because they are able to play in a sand-box with a safety net. You can change some of the code and see what it affects. Tests will fail. Then you inspect those tests and get some context. * When I jump into some complicated code that has no testing around it, I am very timid. I end up studying for sometimes weeks, then make a one line change still hoping that I have not introduced any side-effects. * I have my environment setup, so that I develop my objects in their own test suite, then I have the application itself. When I make changes to my object, I change them in the test suite. I am generally compiling and running the tests at least every 5 minutes. * The very first thing I do when I update my source for the project is run the unit tests. I will instantly know if anyone has checked in code that is broken before I start to work on my next set of changes. Hopefully that is a good starting list.
All of my software is powered by a single Watt.
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
Many people interchange Test Driven Design with automated unit tests. These are two different concepts, each having potential benefits and costs. In Test Driven Design, tests essentially define requirements and are supposed to only be written when specifically identified as a requirement. No software is written until the tests are written. As new requirements are communicated, new tests are written and new code is written or refactored. Unit testing can be done with any methodology. I have worked with people who adhere to Test Driven Design religiously. While I can appreciate the approach when you are working in a completely new domain where your business knowledge is very limited, when working in an environment where you have significant experience, the process slows you down. The word refactor becomes a four letter word $#@!. Unit testing can be an invaluable tool, especially when you have classes with complex business logic. We developed a calculation engine for a leasing company that involved very complex rules and the use of automated unit tests was invaluable as the engine took on new capabilities. I have also found that the use of unit testing forced the design to clean up interfaces between various classes. As has already been said. It's a tool. First get familiar with the tool. Then use it where appropriate.
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
It's very easy to try TDD. Some people take to it, and some just don't particularly enjoy it. At first, I wasn't very impressed by the idea - it just sounded like pointless extra work and verbosity, and after all I'd been enjoying programming for some 15 years without it. But since it was required for a new job, I went along with it, and quickly came to really enjoy the process. Not only is it very comforting to know that you're always only a couple of steps away from a working program, but it also changed the way that I break down and solve problems for the better. YMMV, but I'd strongly recommend that you try it out on some small/personal project, just in case it works for you too.
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
The primary reason TDD has popped up into the mainstream focus is because JavaScript is a crapper of a language. If you don't create a test script after ever new line of JS code it will break. TDD is just bottom up testing versus top down (the way you do it as do most other developers). Well tested top down applications work just as well as TDD apps and if you code properly it will be just as maintainable as TDD. The big difference is TDD takes 3 times longer and 5 times as expensive. Cheers.
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
As has been said, what ever works. I have one caution, though. It is always very tempting to equate no complaints with no bugs or no problems. That is almost never true. TDD has the strong advantage that to some measurable, repeatable degree you can verify the behavior of your code. You can document what has been tested at least somewhat automatically. Then when the complaints come, or when changes are made, testing, regression and anticipation of problems can come naturally in a planned framework. My rule of thumb: if no one is actively looking then no one will find any problems.
blah, blah, blah James W Taylor
-
Not from the guys that advocate TDD. Unless... well, no. A totally unrelated thing, did you ever realize how nice our society is to complete crackpot nutjobs as long as they don't actually drool? Baaack to the topic: it is worthwhile to write unit tests as an exercise (i.e. repeat often, on different topics). This not only teaches you to write them (always good to have some around) but also what code lends itself well to them. if you feel confident, try writing them before the code and see for yourself.
The problem with the TDD crowd is that they are so enamored with it that they now consider it a test driven design. That's right, by writing your tests first, you will end up with a good design.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyQuote:
A totally unrelated thing, did you ever realize how nice our society is to complete crackpot nutjobs as long as they don't actually drool?
You are completely wrong about this. Our society is horrible to people it considers to be "crackpot nutjobs." In our culture, it is perfectly acceptable to ridicule those who have beliefs contrary to one's own beliefs. So, the fewer people believe something, the more ridicule those people will receive for it, most often suffering accusations of having a lower mental capacity. This happens despite unrefutable historical evidence and logical deduction that, in the realm of ideas, popularity and correctness often have little to do with one another. The exception to this is that once a set of beliefs reaches a certain number of people -- a "critical mass" number, if you will -- it becomes politically incorrect to communicate your ridicule publicly. This leads to resentment on the part of closed-minded people. That resentment gets communicated in the form of petty spitefulness, such as through malicious gossip, through ostracization, or through posting semi-anonymous comments complaining about crackpot nutjobs in general. In the case of Ron Paul, for example, his followers reached critical mass at such a high speed that it left closed-minded people's heads spinning. The news media could no longer ridicule him out loud, so they chose to gossip and ostracize. I will leave it to Paul-ites to express the details of this unfairness themselves, but objectively, there is a clear news bias against Paul, and one does not have to be a supporter to see it. I sympathize with him because I am a member of a minority religion that has been right on the line of critical mass for many years, and I have personally suffered extreme ridicule from Christians and atheists alike. Actually, the atheists have been much worse than the Christians, in both the level of vitriol and the utter refusal to acknowledge that a sane person could believe the things that I believe. To such closed-minded people, if you do not believe what they believe, you are obviously a crackpot nutjob, meaning that you are mentally and morally inferior in every way. As someone with an IQ of 155 who has no trouble holding a steady job, who graduated from an Ivy League school with a GPA of 3.69, and who completely disdains mind-altering substances, I find this extremely irritating. What more do I have to do to prove that I am rational? Oh, of co
-
Quote:
A totally unrelated thing, did you ever realize how nice our society is to complete crackpot nutjobs as long as they don't actually drool?
You are completely wrong about this. Our society is horrible to people it considers to be "crackpot nutjobs." In our culture, it is perfectly acceptable to ridicule those who have beliefs contrary to one's own beliefs. So, the fewer people believe something, the more ridicule those people will receive for it, most often suffering accusations of having a lower mental capacity. This happens despite unrefutable historical evidence and logical deduction that, in the realm of ideas, popularity and correctness often have little to do with one another. The exception to this is that once a set of beliefs reaches a certain number of people -- a "critical mass" number, if you will -- it becomes politically incorrect to communicate your ridicule publicly. This leads to resentment on the part of closed-minded people. That resentment gets communicated in the form of petty spitefulness, such as through malicious gossip, through ostracization, or through posting semi-anonymous comments complaining about crackpot nutjobs in general. In the case of Ron Paul, for example, his followers reached critical mass at such a high speed that it left closed-minded people's heads spinning. The news media could no longer ridicule him out loud, so they chose to gossip and ostracize. I will leave it to Paul-ites to express the details of this unfairness themselves, but objectively, there is a clear news bias against Paul, and one does not have to be a supporter to see it. I sympathize with him because I am a member of a minority religion that has been right on the line of critical mass for many years, and I have personally suffered extreme ridicule from Christians and atheists alike. Actually, the atheists have been much worse than the Christians, in both the level of vitriol and the utter refusal to acknowledge that a sane person could believe the things that I believe. To such closed-minded people, if you do not believe what they believe, you are obviously a crackpot nutjob, meaning that you are mentally and morally inferior in every way. As someone with an IQ of 155 who has no trouble holding a steady job, who graduated from an Ivy League school with a GPA of 3.69, and who completely disdains mind-altering substances, I find this extremely irritating. What more do I have to do to prove that I am rational? Oh, of co
A political candidate, in the public arena, comes under intense scrutiny for everything they have said and done in, and out, of elective office: that's the nature of the process. There's lots of ridicule being broadcast 24/7 from both the "right," and the "left," and everywhere in between: that's the nature of mass-media these days. Satire and parody of politicians is a world-wide art-form. But, what does that have to do with your membership in a minority religion ? Do you go around thrusting your beliefs in other peoples' faces in such a way that you compel them to tell you to "take it elsewhere," which you then interpret as "intolerance." Are you on a "mission" of some kind ? Why do you find it necessary to "lay" your beliefs on atheists or anyone else ? Isn't your religion demonstrated as much by your respectful and tolerant conduct towards others who have different points of view as by any statement of its nature, structure, metaphysics, etc. ? In America, at least, you have freedom of religion: why not enjoy that freedom, and avoid those who have biases against your religion for whatever reason. It's illegal to discriminate, in America, in hiring based on religion. It's also against the entire "ethos" of a secular society (and in some cases illegal) to interject your religion into public places financed with public money, or into the private for-profit workplace in such a way that you proselytize other people. But, perhaps you enjoy the controversy; enjoy provoking other people ? Lots of fanatics get off on that; it's often a prime reason they select their brand of provocative creed. Being a member of a "persecuted minority," can make empty, lonely people feel quite "special." Suggested reading to broaden your knowledge of what "intelligence" is: Daniel Goleman, "Emotional Intelligence: Why It Can Matter More Than IQ," and its sequel, "Social Intelligence: The New Science of Social Relationships."
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
-
First, lets make a distinction between xUnit testing frameworks and Test-Driven Development (TDD). xUnit Test Framworks act as a "code-vice" to hold your code in a fixed stable position while you make changes. The driver that manages when the tests are run etc is built into the the framework. The only thing that is left to the developer is to write individual tests to verify functionality. Test Driven Development often uses an xUnit framework, and is a methodology where you write the tests first, watch the test fail calling the unimplemented function. Then the actual code is developed to pass the tests. At first you may simply make the simplest implementation possible. But as more scenarios are determined, more tests are created, and you refactor your implementation. Each time knowing if you last change was a good change, or a bad change. Keep in mind, both of these work best on discrete units of code. Each test suite would verify one class, or algorithm. Trying to test an entire application is not focused enough to be beneficial. I discovered it 3 years ago, and use it for both my work and hobby code. I don't end up writing unit-tests for everything that I write, however, I still develop the tests for the majority of my code. I can't say whether you are missing out on something or not. Every programmer has their own favorite tools, processes, and junk-food to program with. I still run into programmers that prefer trouble-shooting problems using printf rather than the debugger. What I can tell you are the benefits I have experienced, then a few of the inconveniences. 1) I get to use my object interfaces before I have completed their implementation. This has saved me a ton of time when I think I have a good interface defined, only to find out it is too cumbersome, or even unusable when I go to write the tests. At this phase, I actually get to write the code how I would like to use my objects. 2) It is quite often true that I end up with more unit-test code than actual production code. However, I also have less production code than I would have written without the tests driving my development. Why? I quit over-analyzing my objects thinking, "oh, it would be really cool if I added ...". When I write my tests, I write for the functionality that I need, and no more. If I need that cool feature later, I can add it later. 3) I have learned how to write unit-testable production code. It's part of the methodology, you design your objects to be testable. When you imp
Really enjoyed both your detailed posts, Paul, and +5'd them both: lots of meat on them bones. The impression I have about this thread, in general, is: that the general concept of testing is getting discussed simultaneously with the specific formal methodology/discipline of TDD. In the past much of my work (as on what became "Acrobat") was focused hell-bent on achieving proof-of-concept. The day our small team of "skunk-work guerrillas" within Adobe (all from a freshly acquired small company that Adobe gobbled up) had the same PostScript source page, with complex typography and graphics, all looking the same on a Mac, a PC, and the NeXT machine was a big effing deal. "Formal development" ? : rather I should say later Acrobat development grew in the same way a cancer metastasizes :) Interesting to me to see a product out there now (Nitro PDF) which I think the free version of "beats the pants off" the free Acrobat in terms of UI, performance (but, of course, does not have all the enterprise-related bells-and-whistles that you'll pay dearly for to upgrade to a higher-level Acrobat). best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
-
Really enjoyed both your detailed posts, Paul, and +5'd them both: lots of meat on them bones. The impression I have about this thread, in general, is: that the general concept of testing is getting discussed simultaneously with the specific formal methodology/discipline of TDD. In the past much of my work (as on what became "Acrobat") was focused hell-bent on achieving proof-of-concept. The day our small team of "skunk-work guerrillas" within Adobe (all from a freshly acquired small company that Adobe gobbled up) had the same PostScript source page, with complex typography and graphics, all looking the same on a Mac, a PC, and the NeXT machine was a big effing deal. "Formal development" ? : rather I should say later Acrobat development grew in the same way a cancer metastasizes :) Interesting to me to see a product out there now (Nitro PDF) which I think the free version of "beats the pants off" the free Acrobat in terms of UI, performance (but, of course, does not have all the enterprise-related bells-and-whistles that you'll pay dearly for to upgrade to a higher-level Acrobat). best, Bill
"It is the mark of an educated mind to be able to entertain a thought without accepting it." Aristotle
BillWoodruff wrote:
Really enjoyed both your detailed posts, Paul, and +5'd them both: lots of meat on them bones.
Thanks!
BillWoodruff wrote:
The impression I have about this thread, in general, is: that the general concept of testing is getting discussed simultaneously with the specific formal methodology/discipline of TDD.
Yes I agree. I have seen a lot of other vocabulary thrown in through the posts that further muddy the topic. This is something that I have been pondering writing an article about, but the number of articles related to unit-testing has been a bit of a deterrent. However, based on this thread, I may be putting something out soon. Over the last three years I have developed a set of tools to make creating fake objects simpler. I have created a Visual Studio wizard to automatically create a new test suite project for me (that was the most tedious part), and I have discovered quite a few tricks to make my code testable. That's probably what will appear when I can complete this. I am lucky in that my current employer expects unit-tests to appear along with the code review. After others have seen the streamlined process, it has caught on in a grass-roots fashion. The engineers have chosen to do it this way on their own. So that's a bit rewarding. Unfortunately, I don't know of any direct examples for software products developed with TDD, or which have unit-tests. It also seems, that every company has their own way of doing things, and even in each company, every team and then every programmer has their own way they prefer. Just like programming languages, some programmers are a little too passionate about their processes and testing methodologies. I choose to share what works best for me, but I know this process is not for everyone.
All of my software is powered by a single Watt.
-
As has been said, what ever works. I have one caution, though. It is always very tempting to equate no complaints with no bugs or no problems. That is almost never true. TDD has the strong advantage that to some measurable, repeatable degree you can verify the behavior of your code. You can document what has been tested at least somewhat automatically. Then when the complaints come, or when changes are made, testing, regression and anticipation of problems can come naturally in a planned framework. My rule of thumb: if no one is actively looking then no one will find any problems.
blah, blah, blah James W Taylor
James W Taylor wrote:
TDD has the strong advantage that to some measurable, repeatable degree you can verify the behavior of your code
James W Taylor wrote:
My rule of thumb: if no one is actively looking then no one will find any problems.
Well put! :thumbsup:
All of my software is powered by a single Watt.
-
I am a self taught programmer..Though I have a formal degree in Computer Science I learn all programming languages on my own. Did small projects and gone through libraries to learn it. Worked as a freelancer for a while and generally whenever I got requirement I do some prototype on paper and start developing code. I am always able to find the solution to problems and learn on the way. Generally I write part of app , test it , if possible show it to client and take their input to accommodate exception cases and any changes. I am not much into TDD. I did applications that are used by 4000 users at a time and I would say it works perfectly fine. My clients are happy with it. Lot of time I question myself am I missing out on something because I never used TDD ? Your input appreciated.
Zen and the art of software maintenance : rm -rf * Math is like love : a simple idea but it can get complicated.
Should you adopt TDD? Let me answer that question with a question: Have you ever pushed a release and felt anxiety over the idea that you may have inadvertently broken a previously released feature with your new feature? If so, then I would say, "yes, you should adopt some form of automated testing procedures." I don't usually follow the TDD "test first" approach, but I have learned to create all projects using a testable interface based design. I usually add a unit test when I am done - kind of backwards, but it works for me. Also, I don't strive for 100% test coverage; rather, I add tests to methods that have logic, or that transform data in some way. I also like to test things that could easily cause run-time exceptions, like code that relies on magic strings. Route-handling tests in MVC, for example, are great candidates for unit tests - especially since the routes are cascading, so it would be easy to add a new route that messed up other routes. This would be nearly impossible to catch with unit tests on every route. Someone commented that a negative side effect of unit testing is having to refactor the unit tests along with changes. If you read Fowler's book, Refactoring, you will learn to see the refactoring not as a bad side effect, but simply as part of the process of refactoring. You are not done with the refactor until the unit tests are also refactored, compiling and green. It forces you to take a second look at all of those edge cases that you wrote tests for 6 months ago, that you would have otherwise completely forgotten about when you pushed your changes. Once you anticipate this, and accept it as part of the procedure, then it is no longer a negative side effect. Jordan