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?
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
-
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.
About TDD: 1.) It REQUIRES dependency injection. 2.) It REQUIRES a mocking framework like Moq or RhinoMocks. MOCKING IS A PAIN IN THE A$$ 3.) It FORCES you to write code a certain way...(i.e. using dependency injection...which is not terrible, but comes at a cost). 4.) It's only as good as the tests you write...if you don't write all bounds tests, then it's kind of a waste of time to use TDD. 5.) It ONLY tests design, NOT requirements. This seems to be one of the biggest misunderstandings in the industry. For instance, the method may require some pre-condition that is a rule on your team. You can write a test for that. But BUSINESS REQUIREMENTS should not be unit tested (for the most part). 6.) It's good on LARGE COMPLEX projects with many people and a large budget. 7.) Since you write the tests first, and then finish the code to make the tests pass...so there is quite a bit of extra coding (not double the amount, but sometimes even more). In my experience, TDD has been a waste of time because we didn't have the time and training to fully commit to it. It's never lived up to its hype on any project I've used it. WHAT DOES WORK: AUTOMATED INTEGRATION TESTS OF BUSINESS REQUIREMENTS As a .NET developer, I use Microsoft's "moles" framework. This framework does NOT require dependency injection. It essentially stubs out an entire assembly and replaces it in your code. Then you tell the framework what the setup conditions should be. Moles is really cool, because you can mock ANYTHING (even system-level assemblies, which I have done) and it does it automagically for you. It really does allow you to test anything that is too baked into your projects....it's good for legacy projects that didn't follow the dependency-injection rules. I TEST BUSINESS REQUIREMENTS (because I work on small projects and I have to)...and my tests catch most of the bugs...they catch bugs that a unit test won't catch. Basically, I like to write automated use-case tests. I've even gone as far as creating a test database that is created from scratch at the beginning of a test batch (instead of mocking the whole DAL). I unit test only when a method's function is not clear...i.e. I need to verify that the method works with various inputs. I don't unit test obvious crap. DO WHAT MAKES SENSE AND DON'T FOLLOW ANY DOGMATIC CRAP!
-
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
What you appear to have read out of my post was, "Whine whine whine everybodyz meeen to me!!1!1!" I respectfully request that you try reading it again without wearing whatever tinted glasses you were wearing before. I have met plenty of people like the ones you describe, who go around shouting about how all the rest of us are not catering to them. Those people are in every religion, including atheism. But I am not one of them. I am going to try to make my point again, and perhaps I will do a better job of communicating it this time. What I am saying is, the definition of a "crackpot nutjob" is something along the lines of, "Someone who believes something that I find ridiculous." It is not correct (morally or factually) to say, "Jewish people are all crackpot nutjobs." But many people in our culture -- as "tolerant" as you say it is -- would agree that "People who worship Thor are all crackpot nutjobs." Because they find the idea of worshipping Thor to be obviously irrational, it seems clear to them that only irrational people must be able to worship Thor. Thus, Thor-worshippers must be mentally inferior, because they are so stupid that they cannot recognize the silliness of their beliefs. Thus, it is acceptable to categorize them as just a couple points past drooling. I prefer to think in logical terms. Just because your rational thinking leads you to conclusion Y, that does not mean that people who reach conclusion X are irrational. Just because some people who believe X are irrational, that does not mean that all people who believe X are irrational. And just because you find X ridiculous, that does not mean people who believe X are worthy of ridicule as being "crackpot nutjobs." I am speaking here about even people who are, say, Flat Earthers. Just because you and I find their belief absurd, that does not mean they are necessarily mentally inferior. They may be merely working from a different set of premises and evidence. (I am not saying that their premises and evidence are of the same quality as ours, I am saying that their thought processes could very well be equal in quality to ours.) Not only is mocking these people an immoral thing to do, it makes them defensive and less willing to change their minds about what they believe. Attacking people only serves to close the gates of communication. I do not care one whit about whoever it was the "crazy nutjobs" in the original post were. I am merely offended that it is considered acceptable to label people with such a derogatory
-
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.
Since learning BASIC about 20 years ago, and since then lots of languages in between, only a few key things have changed the way I've worked as a programmer over the years. One of them is definitely TDD, trust me it is worth learning. Also IoC and DI are very relevant here - these three things together in my experience make you create better designs, work quicker and protect you from changing requirements (and very often from yourself!). The best situation is that you enjoy learning new stuff - my approach is to try to use a little of something new with each new project, that's worked really well for me over the years.
-
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
Wow, looks like I struck a chord!
miyasudokoro wrote:
In our culture, it is perfectly acceptable to ridicule those who have beliefs contrary to one's own beliefs.
Not in mine.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchy -
Yes, you are definitely missing something. The 4000 users number isn't very indicative of when to use TDD. 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 because your users don't want to wait 3 years until all of them are finished. In that case you need some automated testing.
Wout
IMHO, in such a complex scenario (4000 complex features) I think it would be very difficult to create tests that would probe a significant combination of application states that can be present in real-life scenarios. Concurrency errors come to mind... To back up my opinion, I refer to the fact that when many of us developers test our applications manually, we tend to unconsciously follow a certain usage-test pattern that usually hides nasty errors discovered -often surprisingly early- by other users simply employing a different application-usage pattern. What could be a more invariant usage-pattern than a predefined, scripted test? I'm not against TDD - any technique that advances the state of current software engineering is welcome- however I think it's no panacea, and I often am wary of any technique that might create a false illusion of safety that fosters a relaxed attitude towards code correctness. ;)
-
Wow, looks like I struck a chord!
miyasudokoro wrote:
In our culture, it is perfectly acceptable to ridicule those who have beliefs contrary to one's own beliefs.
Not in mine.
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyWhen there even half the uproar over insults to fringe believers as there is over insults to ethnic minorities, I will agree with you.
-
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.
Thanks for your replies. You have almost persuaded me. one last question: Cost. I presume there are the following costs involved in doing TDD: 1) the cost of the tool for the xUnit tests as you call it 2) the time cost of configuring the tool and setting up the objects and data for the tests, and changing the tests every time the system changes 3) the time costs of running the tests. It looks as if all of this would double the cost of any development, would you agree? If so, in a corporation that cost can be justified, but as an independent developer you run the risk of pricing your system out of the market, especially in an industry open to super-cheap offers from millions of "developers". In your opinions, who actually is willing to bear the cost of this type of project?