What do you think about NUnit?
-
I just downloaded and tried out NUnit, an automated testing facility: http://www.nunit.org/[^] My opinion is that it's overly simplistic. I don't buy into the idea that "some testing is better than no testing", when the testing in question is so simple as to be meaningless. On the other hand, to make a sophisticated test requires as much coding as the algorithm under test. Actually more, because if I think of the kind of testing that I need, which involves a lot of database validation, the test code also needs the ability to create the test data, run the functions under test, inspect the results, and then reset the database to its original state. That's a lot of code. And another thing--testing involves a lot of different issues. Does the function succeed with expected parameters? Does the function properly handle bad parameters? What about performance as a pass/fail criteria? What about dependencies to other modules, third party software, etc? How do you simulate the failure of a connection to see how the function handles itself? Beyond simplistic testing, I think a lot more needs to be done than what NUnit provides. So, now that I've totally biased you, what do you think about NUnit? Do you use it? Do you feel it's useful? Are my criticism out of line? Marc Latest AAL Article My blog Join my forum!
-
I just downloaded and tried out NUnit, an automated testing facility: http://www.nunit.org/[^] My opinion is that it's overly simplistic. I don't buy into the idea that "some testing is better than no testing", when the testing in question is so simple as to be meaningless. On the other hand, to make a sophisticated test requires as much coding as the algorithm under test. Actually more, because if I think of the kind of testing that I need, which involves a lot of database validation, the test code also needs the ability to create the test data, run the functions under test, inspect the results, and then reset the database to its original state. That's a lot of code. And another thing--testing involves a lot of different issues. Does the function succeed with expected parameters? Does the function properly handle bad parameters? What about performance as a pass/fail criteria? What about dependencies to other modules, third party software, etc? How do you simulate the failure of a connection to see how the function handles itself? Beyond simplistic testing, I think a lot more needs to be done than what NUnit provides. So, now that I've totally biased you, what do you think about NUnit? Do you use it? Do you feel it's useful? Are my criticism out of line? Marc Latest AAL Article My blog Join my forum!
Good tool that does what it's mean to.. automate simple testing. I use it, and like it, but do not rely solely on it. ~Mike Stanbrook
-
I just downloaded and tried out NUnit, an automated testing facility: http://www.nunit.org/[^] My opinion is that it's overly simplistic. I don't buy into the idea that "some testing is better than no testing", when the testing in question is so simple as to be meaningless. On the other hand, to make a sophisticated test requires as much coding as the algorithm under test. Actually more, because if I think of the kind of testing that I need, which involves a lot of database validation, the test code also needs the ability to create the test data, run the functions under test, inspect the results, and then reset the database to its original state. That's a lot of code. And another thing--testing involves a lot of different issues. Does the function succeed with expected parameters? Does the function properly handle bad parameters? What about performance as a pass/fail criteria? What about dependencies to other modules, third party software, etc? How do you simulate the failure of a connection to see how the function handles itself? Beyond simplistic testing, I think a lot more needs to be done than what NUnit provides. So, now that I've totally biased you, what do you think about NUnit? Do you use it? Do you feel it's useful? Are my criticism out of line? Marc Latest AAL Article My blog Join my forum!
Well, I did not really look at your link but unit testing which is what I take the title to imply is just the first step in any testing program. All it is intended to do is to test the lowlevel (units). To me at least unit testing is not intended to a complete set, but one that is very repeatable and quick, again as a first step. When you find an error you add that error to the test scripts. So yes it is useful, but as you point out if it is all you are doing you will have problems. "For as long as I can remember, I have had memories. Colin Mochrie."
-
I just downloaded and tried out NUnit, an automated testing facility: http://www.nunit.org/[^] My opinion is that it's overly simplistic. I don't buy into the idea that "some testing is better than no testing", when the testing in question is so simple as to be meaningless. On the other hand, to make a sophisticated test requires as much coding as the algorithm under test. Actually more, because if I think of the kind of testing that I need, which involves a lot of database validation, the test code also needs the ability to create the test data, run the functions under test, inspect the results, and then reset the database to its original state. That's a lot of code. And another thing--testing involves a lot of different issues. Does the function succeed with expected parameters? Does the function properly handle bad parameters? What about performance as a pass/fail criteria? What about dependencies to other modules, third party software, etc? How do you simulate the failure of a connection to see how the function handles itself? Beyond simplistic testing, I think a lot more needs to be done than what NUnit provides. So, now that I've totally biased you, what do you think about NUnit? Do you use it? Do you feel it's useful? Are my criticism out of line? Marc Latest AAL Article My blog Join my forum!
From reading your previous articles, I'm sure you know that any system is comprised of 1) data and 2) algorithms that process that data. The systems that are the hardest to maintain and debug are those that require that all the data and all the algorithms (methods) are implemented and working, before you can begin debugging them. To the extent that NUnit forces small module size and complete testing of a module, then yes, it's better than nothing. The other aspect you didn't mention is, what if the "real" database wasn't available? Would it be possible to do any debugging or testing without it? Is it possible to do development offsite without it? These are all things that unit testing makes you think about. HPS HwndSpy - GUI developer's aid to visually locate and inspect windows. For the month of August only, use coupon code CP-81239 for 30% off.
-
I just downloaded and tried out NUnit, an automated testing facility: http://www.nunit.org/[^] My opinion is that it's overly simplistic. I don't buy into the idea that "some testing is better than no testing", when the testing in question is so simple as to be meaningless. On the other hand, to make a sophisticated test requires as much coding as the algorithm under test. Actually more, because if I think of the kind of testing that I need, which involves a lot of database validation, the test code also needs the ability to create the test data, run the functions under test, inspect the results, and then reset the database to its original state. That's a lot of code. And another thing--testing involves a lot of different issues. Does the function succeed with expected parameters? Does the function properly handle bad parameters? What about performance as a pass/fail criteria? What about dependencies to other modules, third party software, etc? How do you simulate the failure of a connection to see how the function handles itself? Beyond simplistic testing, I think a lot more needs to be done than what NUnit provides. So, now that I've totally biased you, what do you think about NUnit? Do you use it? Do you feel it's useful? Are my criticism out of line? Marc Latest AAL Article My blog Join my forum!
NUnit has some obvious shortcomings , but NUnit test cases do help specially in bigger and longer projects. In bigger projects, cost of defects/bugs is typically must higher than coding sophisticated test cases. Atleast the NUnit test cases should be there for critical areas. In small testing most of Unit testing is done manually. Deepak Khajuria
-
I just downloaded and tried out NUnit, an automated testing facility: http://www.nunit.org/[^] My opinion is that it's overly simplistic. I don't buy into the idea that "some testing is better than no testing", when the testing in question is so simple as to be meaningless. On the other hand, to make a sophisticated test requires as much coding as the algorithm under test. Actually more, because if I think of the kind of testing that I need, which involves a lot of database validation, the test code also needs the ability to create the test data, run the functions under test, inspect the results, and then reset the database to its original state. That's a lot of code. And another thing--testing involves a lot of different issues. Does the function succeed with expected parameters? Does the function properly handle bad parameters? What about performance as a pass/fail criteria? What about dependencies to other modules, third party software, etc? How do you simulate the failure of a connection to see how the function handles itself? Beyond simplistic testing, I think a lot more needs to be done than what NUnit provides. So, now that I've totally biased you, what do you think about NUnit? Do you use it? Do you feel it's useful? Are my criticism out of line? Marc Latest AAL Article My blog Join my forum!
I think its a good tool that does was it says it does. They do say that being a small group they have to focus on the core application rather than any nice to haves, though they are looking for other people to help out. I was thinking about adding in a tool to do some kind of historical perfomance measuring agaist each of the tests and beiong able to graph it in the app. All in good time though.
"Je pense, donc je mange." - Rene Descartes 1689 - Just before his mother put his tea on the table. Shameless Plug - Distributed Database Transactions in .NET using COM+
-
I just downloaded and tried out NUnit, an automated testing facility: http://www.nunit.org/[^] My opinion is that it's overly simplistic. I don't buy into the idea that "some testing is better than no testing", when the testing in question is so simple as to be meaningless. On the other hand, to make a sophisticated test requires as much coding as the algorithm under test. Actually more, because if I think of the kind of testing that I need, which involves a lot of database validation, the test code also needs the ability to create the test data, run the functions under test, inspect the results, and then reset the database to its original state. That's a lot of code. And another thing--testing involves a lot of different issues. Does the function succeed with expected parameters? Does the function properly handle bad parameters? What about performance as a pass/fail criteria? What about dependencies to other modules, third party software, etc? How do you simulate the failure of a connection to see how the function handles itself? Beyond simplistic testing, I think a lot more needs to be done than what NUnit provides. So, now that I've totally biased you, what do you think about NUnit? Do you use it? Do you feel it's useful? Are my criticism out of line? Marc Latest AAL Article My blog Join my forum!
I like it. From my experience unit testing is ad hoc activity in most companies. Observing the V testing model, most companies dedicate resources to validation, functional testing and acceptance tests. For real time or other critical systems (e.g. call centers) system testing is done for limited number of scenarios. But...unit testing? This is done by stepping with the debugger through the code in most places I worked for. To actually have a test script and the possibility to automate it (and do regression) is a bonus. It is similar with integration testing. NUNIT supports automated unit testing. And no more. Tomaz
-
I just downloaded and tried out NUnit, an automated testing facility: http://www.nunit.org/[^] My opinion is that it's overly simplistic. I don't buy into the idea that "some testing is better than no testing", when the testing in question is so simple as to be meaningless. On the other hand, to make a sophisticated test requires as much coding as the algorithm under test. Actually more, because if I think of the kind of testing that I need, which involves a lot of database validation, the test code also needs the ability to create the test data, run the functions under test, inspect the results, and then reset the database to its original state. That's a lot of code. And another thing--testing involves a lot of different issues. Does the function succeed with expected parameters? Does the function properly handle bad parameters? What about performance as a pass/fail criteria? What about dependencies to other modules, third party software, etc? How do you simulate the failure of a connection to see how the function handles itself? Beyond simplistic testing, I think a lot more needs to be done than what NUnit provides. So, now that I've totally biased you, what do you think about NUnit? Do you use it? Do you feel it's useful? Are my criticism out of line? Marc Latest AAL Article My blog Join my forum!
Marc Clifton wrote: On the other hand, to make a sophisticated test requires as much coding as the algorithm under test I don't know about that. I'm no TDD expert, but I'd guess that if your tests are too complicated then your code isn't factored highly enough. As for the database validation, yeah that's a tricky one. People seem to to be leaning towards maintaing multiple DB's as many as three. One of them is fairly fluid of course. I'm pretty sure you can automate the process of populating a test DB from within the test code itself. Better than nothing. Marc Clifton wrote: Does the function succeed with expected parameters? A proper NUnit test will confirm that. Marc Clifton wrote: Does the function properly handle bad parameters? A proper NUnit test will confirm that. Marc Clifton wrote: What about performance as a pass/fail criteria? The beauty of TDD is that once you have confidence in your tests, refactoring becomes a breeze because you'll know immediately what will have caused a breakage in some interdependent object. This means you can more agressively refactor code for performance enhancements. Marc Clifton wrote: What about dependencies to other modules, third party software, etc? I guess the assumption is that they have already been unit tested :sigh: Marc Clifton wrote: How do you simulate the failure of a connection to see how the function handles itself? I think mock objects would come in useful here. http://www.nmock.sourceforge.ne[^] Also, join a TDD newsgroup such as http://groups.yahoo.com/group/testdrivendevelopment[^] They discuss these very issues everyday in some detail. What's the difference between a C++ programmer and God? God knows he's not a C++ programmer : anon
-
I just downloaded and tried out NUnit, an automated testing facility: http://www.nunit.org/[^] My opinion is that it's overly simplistic. I don't buy into the idea that "some testing is better than no testing", when the testing in question is so simple as to be meaningless. On the other hand, to make a sophisticated test requires as much coding as the algorithm under test. Actually more, because if I think of the kind of testing that I need, which involves a lot of database validation, the test code also needs the ability to create the test data, run the functions under test, inspect the results, and then reset the database to its original state. That's a lot of code. And another thing--testing involves a lot of different issues. Does the function succeed with expected parameters? Does the function properly handle bad parameters? What about performance as a pass/fail criteria? What about dependencies to other modules, third party software, etc? How do you simulate the failure of a connection to see how the function handles itself? Beyond simplistic testing, I think a lot more needs to be done than what NUnit provides. So, now that I've totally biased you, what do you think about NUnit? Do you use it? Do you feel it's useful? Are my criticism out of line? Marc Latest AAL Article My blog Join my forum!
Marc Clifton wrote: I don't buy into the idea that "some testing is better than no testing", when the testing in question is so simple as to be meaningless. Hmm.. I think it's good to have tests which asserts that invariants hold for a class at any given time (before and after a call to one of its public members). By testing this over and over during the development process, it's easier to spot bugs as you introduce them. :) At least bugs which are wrong by design. -- N = { n_i_ | n0 = 0, n_i_ + 1 = n_i_ + 1, i ³ 0 }
-
I just downloaded and tried out NUnit, an automated testing facility: http://www.nunit.org/[^] My opinion is that it's overly simplistic. I don't buy into the idea that "some testing is better than no testing", when the testing in question is so simple as to be meaningless. On the other hand, to make a sophisticated test requires as much coding as the algorithm under test. Actually more, because if I think of the kind of testing that I need, which involves a lot of database validation, the test code also needs the ability to create the test data, run the functions under test, inspect the results, and then reset the database to its original state. That's a lot of code. And another thing--testing involves a lot of different issues. Does the function succeed with expected parameters? Does the function properly handle bad parameters? What about performance as a pass/fail criteria? What about dependencies to other modules, third party software, etc? How do you simulate the failure of a connection to see how the function handles itself? Beyond simplistic testing, I think a lot more needs to be done than what NUnit provides. So, now that I've totally biased you, what do you think about NUnit? Do you use it? Do you feel it's useful? Are my criticism out of line? Marc Latest AAL Article My blog Join my forum!
Sorry but everytime I read 'Nunit' I read it as 'Inuit'...:~ :sigh:
"werewnt we going to run off and start a convent on as islandf]"
-David Wulff, again on MSN while plastered...
Jonathan 'nonny' Newman Homepage [www.nonny.com] [^] Bob Chum Dev site [^] -
I just downloaded and tried out NUnit, an automated testing facility: http://www.nunit.org/[^] My opinion is that it's overly simplistic. I don't buy into the idea that "some testing is better than no testing", when the testing in question is so simple as to be meaningless. On the other hand, to make a sophisticated test requires as much coding as the algorithm under test. Actually more, because if I think of the kind of testing that I need, which involves a lot of database validation, the test code also needs the ability to create the test data, run the functions under test, inspect the results, and then reset the database to its original state. That's a lot of code. And another thing--testing involves a lot of different issues. Does the function succeed with expected parameters? Does the function properly handle bad parameters? What about performance as a pass/fail criteria? What about dependencies to other modules, third party software, etc? How do you simulate the failure of a connection to see how the function handles itself? Beyond simplistic testing, I think a lot more needs to be done than what NUnit provides. So, now that I've totally biased you, what do you think about NUnit? Do you use it? Do you feel it's useful? Are my criticism out of line? Marc Latest AAL Article My blog Join my forum!
I find it interesting that a guy interested in Agile methods and Extreme Programming hasn't bought into the concept of unit testing. I don't mean to be critical - you have found success in your practice and I commend that. In The Pragmatic Programmer, Hunt points out: "All software you write will be tested - if not by you and your team, then by the eventual users - so you might as well plan on testing it thoroughly." Your software is already being tested. A good bit of reading concerning the efficiency of testing is in Refactoring by Martin Fowler, chapter four. He explains that most programming time is spent debugging. With testing, not only does refactoring become feasible, but also debugging time is diminished. My own experience is limited. I’m on my first extensively tested project. I have found that the best part is the confidence brought about through testing. I’m not yet a very good test writer, but experience is making me better. I am more confident that the code that I write passes some measure of success and I can refactor without concern that I’ll break something. Hope this helps. Here's[^] XP's take on testing.
α.γεεκ
Fortune passes everywhere.
Duke Leto Atreides -
I find it interesting that a guy interested in Agile methods and Extreme Programming hasn't bought into the concept of unit testing. I don't mean to be critical - you have found success in your practice and I commend that. In The Pragmatic Programmer, Hunt points out: "All software you write will be tested - if not by you and your team, then by the eventual users - so you might as well plan on testing it thoroughly." Your software is already being tested. A good bit of reading concerning the efficiency of testing is in Refactoring by Martin Fowler, chapter four. He explains that most programming time is spent debugging. With testing, not only does refactoring become feasible, but also debugging time is diminished. My own experience is limited. I’m on my first extensively tested project. I have found that the best part is the confidence brought about through testing. I’m not yet a very good test writer, but experience is making me better. I am more confident that the code that I write passes some measure of success and I can refactor without concern that I’ll break something. Hope this helps. Here's[^] XP's take on testing.
α.γεεκ
Fortune passes everywhere.
Duke Leto AtreidesJim Stewart wrote: hasn't bought into the concept of unit testing. I guess I haven't, at least in the way that the Agile community presents the concept. I certainly understand the need, I test my code (but I don't write test routines first), and I haven't found the need to write unit tests. I have instead relied on assertions, instrumentation, and code walk-throughs, in addition to relying heavily on "proven" functionality in my AAL. At this point, the kind of coding that I do is not low-level--I hardly ever write low level GUI or data access functions anymore. It's mostly architectural design and then scripted "glue", tying together components that I know work through eight years of re-use. Injecting a unit test in such an environment would be valuable, perhaps, but also very complex. For example, to test the billing process of my boatyard client requires a lot of setup and teardown of necessary database records--stuff that has been tested and proven to work as part of other workflows. The "billing" test would essentially have to recreate the data entry components that the billing system relies on. I simply don't see the cost benefit of it. So, my lack of experience with unit testing, coupled with my significant experiences in other ways to reduce bugs, coupled with a heavy dose of "talk is easy, but doing it is actually hard" makes me rather a doubting Thomas. And you said it yourself "I’m not yet a very good test writer, but experience is making me better", which indicates to me that unit testing is a skill, not something that happens automatically. I think the Agile community is ignoring the fact that skills require training. This (from the XP link--thanks!): There is a rhythm to developing software unit test first. You create one test to define some small aspect of the problem at hand. Then you create the simplest code that will make that test pass. Then you create a second test. Now you add to the code you just created to make this new test pass, but no more! Not until you have yet a third test. You continue until there is nothing left to test. is a gross oversimplification, IMO. There is ALWAYS something left to test, and believe me, the end-user will find the pathway, data, or other condition that I forgot to test for. And the idea that "when all the tests pass, the code is finished", is total BS, IMO, because it relies entirely on good tests. And as you pointed out, writing good tests comes with experience. So, with all that sa
-
Jim Stewart wrote: hasn't bought into the concept of unit testing. I guess I haven't, at least in the way that the Agile community presents the concept. I certainly understand the need, I test my code (but I don't write test routines first), and I haven't found the need to write unit tests. I have instead relied on assertions, instrumentation, and code walk-throughs, in addition to relying heavily on "proven" functionality in my AAL. At this point, the kind of coding that I do is not low-level--I hardly ever write low level GUI or data access functions anymore. It's mostly architectural design and then scripted "glue", tying together components that I know work through eight years of re-use. Injecting a unit test in such an environment would be valuable, perhaps, but also very complex. For example, to test the billing process of my boatyard client requires a lot of setup and teardown of necessary database records--stuff that has been tested and proven to work as part of other workflows. The "billing" test would essentially have to recreate the data entry components that the billing system relies on. I simply don't see the cost benefit of it. So, my lack of experience with unit testing, coupled with my significant experiences in other ways to reduce bugs, coupled with a heavy dose of "talk is easy, but doing it is actually hard" makes me rather a doubting Thomas. And you said it yourself "I’m not yet a very good test writer, but experience is making me better", which indicates to me that unit testing is a skill, not something that happens automatically. I think the Agile community is ignoring the fact that skills require training. This (from the XP link--thanks!): There is a rhythm to developing software unit test first. You create one test to define some small aspect of the problem at hand. Then you create the simplest code that will make that test pass. Then you create a second test. Now you add to the code you just created to make this new test pass, but no more! Not until you have yet a third test. You continue until there is nothing left to test. is a gross oversimplification, IMO. There is ALWAYS something left to test, and believe me, the end-user will find the pathway, data, or other condition that I forgot to test for. And the idea that "when all the tests pass, the code is finished", is total BS, IMO, because it relies entirely on good tests. And as you pointed out, writing good tests comes with experience. So, with all that sa
Testing as a skill Writing tests is a non-trivial skill. No doubt. I often wind up with more code in the test than the code being tested. I do not, however see that as an impediment. Writing software, heck, even driving are non-trivial skills. That does not mean that they should not be employed. They do have their place, though. Testing during development In the XP world, writing unit tests is part of the development cycle, not the maintenance cycle. Having unit tests become beneficial during maintenance: Marc Clifton wrote: the end-user will find the pathway, data, or other condition that I forgot to test for ...means an opportunity to write another test to ensure that that pathway is forever closed. Were you starting out on a new venture, then would be the time to invest in the effort of unit testing. Testing is complete In Extreme Programming Installed (Jeffries, et al), chapter 34 is entitled Everything That Could Possibly Break. This chapter is a discussion about what to test. Marc Clifton wrote: There is ALWAYS something left to test There are academics who have proven that it is impossible to test software 100% against all possibilities. That does not mean that it is futile to try. Even with my limited experience in testing, the process has caught many errors that would have made it to my customer. I admit that I'm not yet up to the test-first paradigm, but I am striving towards it. Marc Clifton wrote: And the idea that "when all the tests pass, the code is finished", is total BS, IMO, because it relies entirely on good tests. I must respectfully disagree. When do you know when you're finished, now? You have some standard (perhaps mental, perhaps documentary) against which you measure the program you are writing. When it meets that standard (passes the test) you christen it complete. The XP model just quantifies that concept. Marc Clifton wrote: So, with all that said, what would you say "writing good tests comes with experience" actually means? What is "a good test"? Is this something quantifiable? My tests are maturing, both with my experience and my study of others who know more than me. When I find a bug, I write a new test to ensure that it won't happen again. Philosophically, a good test is one which ensures desired conditions are met and undesired conditions are absent. I think your question might
-
Testing as a skill Writing tests is a non-trivial skill. No doubt. I often wind up with more code in the test than the code being tested. I do not, however see that as an impediment. Writing software, heck, even driving are non-trivial skills. That does not mean that they should not be employed. They do have their place, though. Testing during development In the XP world, writing unit tests is part of the development cycle, not the maintenance cycle. Having unit tests become beneficial during maintenance: Marc Clifton wrote: the end-user will find the pathway, data, or other condition that I forgot to test for ...means an opportunity to write another test to ensure that that pathway is forever closed. Were you starting out on a new venture, then would be the time to invest in the effort of unit testing. Testing is complete In Extreme Programming Installed (Jeffries, et al), chapter 34 is entitled Everything That Could Possibly Break. This chapter is a discussion about what to test. Marc Clifton wrote: There is ALWAYS something left to test There are academics who have proven that it is impossible to test software 100% against all possibilities. That does not mean that it is futile to try. Even with my limited experience in testing, the process has caught many errors that would have made it to my customer. I admit that I'm not yet up to the test-first paradigm, but I am striving towards it. Marc Clifton wrote: And the idea that "when all the tests pass, the code is finished", is total BS, IMO, because it relies entirely on good tests. I must respectfully disagree. When do you know when you're finished, now? You have some standard (perhaps mental, perhaps documentary) against which you measure the program you are writing. When it meets that standard (passes the test) you christen it complete. The XP model just quantifies that concept. Marc Clifton wrote: So, with all that said, what would you say "writing good tests comes with experience" actually means? What is "a good test"? Is this something quantifiable? My tests are maturing, both with my experience and my study of others who know more than me. When I find a bug, I write a new test to ensure that it won't happen again. Philosophically, a good test is one which ensures desired conditions are met and undesired conditions are absent. I think your question might
Hi Jim, Thank you for taking the time to respond--what you say makes a lot of sense and is helping me see things from a different perspective. Especially: Jim Stewart wrote: I must respectfully disagree. When do you know when you're finished, now? You have some standard (perhaps mental, perhaps documentary) against which you measure the program you are writing. When it meets that standard (passes the test) you christen it complete. The XP model just quantifies that concept. Obvious as it now seems, reading what you wrote, I simply hadn't realized this point. I've had a lot of discussions with different people, both proponents and opponents of the "test-first" concept, unit testing, and the subject of testing in general. Odd as it may seem, you are the first person that I've talked to that I feel has provided the necessary "ah ha!" experience to understand what XP is trying to say. I'll definitely be diving into this subject deeper, with your comments in mind. Thank you! Marc Latest AAL Article My blog Join my forum!
-
Hi Jim, Thank you for taking the time to respond--what you say makes a lot of sense and is helping me see things from a different perspective. Especially: Jim Stewart wrote: I must respectfully disagree. When do you know when you're finished, now? You have some standard (perhaps mental, perhaps documentary) against which you measure the program you are writing. When it meets that standard (passes the test) you christen it complete. The XP model just quantifies that concept. Obvious as it now seems, reading what you wrote, I simply hadn't realized this point. I've had a lot of discussions with different people, both proponents and opponents of the "test-first" concept, unit testing, and the subject of testing in general. Odd as it may seem, you are the first person that I've talked to that I feel has provided the necessary "ah ha!" experience to understand what XP is trying to say. I'll definitely be diving into this subject deeper, with your comments in mind. Thank you! Marc Latest AAL Article My blog Join my forum!
Thank you for the kind words. Anytime you wish to continue the discussion, please write.
α.γεεκ
Fortune passes everywhere.
Duke Leto Atreides