|
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.
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
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! 
All of my software is powered by a single Watt.
|
|
|
|
|
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
|
|
|
|
|
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!
|
|
|
|
|
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.
|
|
|
|
|
It appears that I survived the last of the qualifying exams! I took the last exam this afternoon and I'm still alive, so it's all over except waiting for the results. This has been a killer week, but it is now over.
Assuming I passed, no more tests, no more exams, no more classes, no more homework! All I have left is the fun stuff!
Of course I said that once before -- maybe about 37 or 38 years ago ...
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
Bravo, Walt!
I hope you did well, and I expect nothing less than Excellent...![Beer | [beer]](https://www.codeproject.com/script/Forums/Images/beer.gif)
Will Rogers never met me.
|
|
|
|
|
|
Congrats Walt, it's always good when the hard stuff is past you else
how would you enjoy the fun stuff?
|
|
|
|
|
Yeah, the only reason to do the hard stuff is so you can get to the fun stuff!
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
 Agreed!
But why is it that the fun stuff is directly proportionate to the inverse of the bad stuff?
|
|
|
|
|
Congratulations, Walt!
/ravi
|
|
|
|
|
Congratualtions!
Walt Fair, Jr. wrote: Of course I said that once before -- maybe about 37 or 38 years ago ...
What a challenge!
What have been your new studies about?
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: What have been your new studies about?
I'm working on a PhD in petroleum engineering. I left U of Texas and went to work after getting an MS in 1975, so it's been "interesting" going back to school after all these years! However, assuming I passed the 3 qualifying exams, I've satisfied all the requirements in 1 year, other than my research, defense, etc. That should be the fun part!
There were times I thought this past year would kill me, but I survived, as did all the professors.
With age comes insanity, I think.
CQ de W5ALT
Walt Fair, Jr., P. E.
Comport Computing
Specializing in Technical Engineering Software
|
|
|
|
|
"no more tests, no more exams, no more classes, no more homework"
But you missed the whole point! Life is "more tests, more exams, more classes, more homework"!
If you consider this "fun stuff", you'll have a great time...
bwa
|
|
|
|
|
A short time ago I posted about a mysterious slowdown of my super zippy Win7 PC. This week I experimented a bit, mostly by leaving Outlook off except to briefly check the mail. I usually leave it running all the time. After a week, the PC is still running like a demon without a whimper. It even bent over behaved like a good altar boy for Patch Tuesday, accepting the "wafer" with nary a tear...
I'm thinking that maybe, just possibly, keeping 30,000+ emails in my Inbox(es) - many with large attachments - might not be an optimal solution. I wonder what this Archive thingy does?
Will Rogers never met me.
|
|
|
|
|
A good rule of thumb (Microsofts, not mine) is to keep the mailbox below 2GB.
I cant remember the reasoning anymore, but I remember that it was properly motivated trough.
|
|
|
|
|
The pst files couldn't be read above 2GB for the longest time.
If your file got that big you would inevitably end up with a crash, and you would have to go to a third party tool to recover the information.
That was the old reason. I think they've overcome that barrier.
_____________________________
Give a man a mug, he drinks for a day. Teach a man to mug...
The difference between an ostrich and the average voter is where they stick their heads.
|
|
|
|
|
Roger Wright wrote: I wonder what this Archive thingy does?
The last time I tried to use this Outlook insisted on prompting me for the location of the archive file every time it opened. It drove me mad for several months!
See if you can crack this: b749f6c269a746243debc6488046e33f
So far, no one seems to have cracked this!
The unofficial awesome history of Code Project's Bob!
"People demand freedom of speech to make up for the freedom of thought which they avoid."
|
|
|
|
|
I've believed for years that outlook just plain sucks.
I'd go off on a rant but the problem is that I haven't found an email client that I think sucks less.
_____________________________
Give a man a mug, he drinks for a day. Teach a man to mug...
The difference between an ostrich and the average voter is where they stick their heads.
|
|
|
|
|
Me with a new transmission line to build, stuck supervising the Customer Service clerks; the pain of it! Our POS software is excellent within its genre, but like all such products, it sucks. Imagine taking payments from customers and having three separate buttons to click - one to open the drawer, one to print a receipt, and one OK button to post the transaction into a temporary file called a batch. It's a PITA, and the girls don't always get it right. When they don't my day gets ruined by having to figure out what went wrong and to make it right.
Today's scenario - cashier 1 starts a transaction, completes it, but misses the final step - clicking OK. Later, cashier 2 opens a transaction, completes it, and remembers to click OK. The next day the accountant updates both batches to the main database and there's an error. What I discovered after spending most of the day comparing receipt journal tapes is that each time this happens, both transactions are assigned the same receipt number; a new receipt number is not assigned until the click on the OK button occurs. From the symptoms, I infer that the receipt number is used as part of the primary key in the database, and on updating, if a duplicate is discovered, that record is either dumped, or the two are mixed. Evidence of mixing comes from a posting list that shows the initials of cashier 2 on some of the transactions entered by cashier 1. In any event, the system is corrupting itself whenever a relatively minor procedural error is committed by an employee.
I can think of a half dozen ways to prevent this, and I'm sure that most of you can think of far more, since most of you do this for a living, while I just dabble in software and build power lines instead. But it's been my experience, over and over, that programmers who build and maintain industry-specific software like this have never spent a day of their lives actually working in the industry. They have an idealized concept of what the software should do and how it should behave, but having no experience, they have no idea how it will actually be used in the real world. It is my firm belief that anyone who writes this stuff should be required to spend one year actually working in the target industry, doing the processes that the software is intended to perform, before being allowed to write a single line of code.
Will Rogers never met me.
|
|
|
|
|
Roger Wright wrote: When they don't my day gets ruined by having to figure out what went wrong and to make it right.
Sounds like a case for log files.
Roger Wright wrote: It is my firm belief that anyone who writes this stuff should be required to spend one year actually working in the target industry, doing the processes that the software is intended to perform, before being allowed to write a single line of code.
But then I'd be one of them!
"I have a theory that the truth is never told during the nine-to-five hours. "
— Hunter S. Thompson
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
