video is fine. im watching it now 
its a viddler player video so will need flash and JS enabled…
and if you cant get it working then try searching for robert martin software craftsmanship and ethics. im pretty sure infoworld has a copy of it… it explains the exact thing you want an answer for, which is whether or not TDD is redundant.
Yes, it is working now. :shrug: It was a broken link before. 
OK W2ttsy, I see the point and I’m not being lazy because I’m willing to do it but my original question is that it seems backwards because I’m working by and for myself and waiting for no one except me. It’s sort of like since I’m the sole programmer and sole developer and sole customer I tend to know what I’m going to do so that any test I write is going to pass the way I am planning to write out the code. It seems that I’m writing test that pass with my code instead of writing the code to pass the tests. It just feels backwards. Sort of like a teacher asking the student what she should include on his test to make sure he passes it.
Of course they fail before I start writing because what they’re looking for doesn’t yet exist. I mean I may as well have tests that just look for the existence of the method I’m planning because when I write it it will most likely do what I need it to do.
i think you have highlighted the problems yourself.
you are writing the tests after writing the code. This is wrong. The test should be written without an idea of implementation. After the test is written, you can then write whatever code you like to insure that the test passes…
as a sole developer, it may seem a bit odd to do this exercise, but you have to remember that its a style or methodology to follow. Once you get into the habit of doing these, then you will scream for mercy when you join a project that doesnt follow TDD…
perhaps reading the wikipedia article on TDD will be helpful in understanding the way it should be adopted.
at the end of the day, if you cant see value in doing it, then dont. however, if you are also worried about quality control or pitching for projects/work in a TDD based environment, then its worth adopting this style of coding…
if you want, i would suggest purchasing some of the starter licenses for atlassian’s products. Their continuous integration server, issue tracker and source code viewer are top notch and will help you with TDD… Bamboo the CI server is especially good here, as you can get fairly quick feedback on the tests your are conducting.
Tests are needed to do real refactoring
Most of you guys already write tests. Time and time again I see developers trash the concept of testing, yet they write tests, just informally.
I used to do just that. I’d have a tests/ folder. In there’d I’d put scripts that tested my code:
<?php
$user= new User(1);
var_dump( $user->load() );
?>
(then I’d load that in the browser, as I edited code I could reload and see how my changed took effect. I wrote code that gave me feedback).
In the early 60s and 70s programmers did this with computer print outs. Developers working on large systems would write programs that would print literally 100s of pages of output. One day someone said why not make the tests more “granular”.
“tests” in the TDD sense just make it more granular, in terms of assertions. You don’t have to test at a low level for it to be rediculous. If you tried that and had too many tests, you did it wrong. You want your tests to read like a high level language. Your tests themselves should have “high level” utility methods for doing “test stuff”. Your tests should read like English. They are executable specifications.
Take a look at the tests for Swift Mailer, or Zend Framework (more complex)
Don’t think of tests as tests. Think of them as executible specifications. The intention of TDD is NOT to test your application. That is why people came up with BDD to make that more clear.
There’s software testing, and then theres test driven development. I am an advocate of one not the other. Tests are necessary to build software that would otherwise yield high cyclomatic complexity. When you start building frameworks, or programming languages, that have infinite real world use scenarios, it becomes necessary to to TDD, in my opinion.
If you can’t go into your code and just start renaming stuff (example methods) that you think would be better renamed, then you aren’t well off. In a good TDD system its almost impossible to find duplicated code. Think of TDD like assisted programming. There is much less fear involved. After a while of doing real refactoring you can program real fast. Need to move some methods from one object to the other? Just cut and paste. RUn the tests. They fail? Oh we forgot a variable scope, update that, run the tests again. Still fail? Oh forgot to rename something else, run them again, they pass. Commit our code, write new tests… its a rapid cycle.
Try it for 30 days. Don’t write tests that test your setters and getters. Do it with something that has real behavior. (example I use it to develop my www.vehiclefits.com software. I feel like I would not have produced software that was as extensive otherwise).
DOnt think of it as a bug prevention technique. Its a software methodology.
i think the biggest problem is that its named “test driven development” and people often associate it with the QA style testing. Really it should be functional driven development or something similar.
The “tests” are based on insuring that all the functionality is captured in the application correctly. As jshpro2 stated, it is more about checking the business logic is complete, than the elegance of the code written.
No, that’s not what I’m saying. I am writing tests first, it’s just seems that since I have to define what I want tested the code is obvious. Does that make sense? I’m saying that the idea of how to code is inherent to writing the tests.
I prefer to think of it as Test Driven Design and is how I usually push it when I’m teaching it.
well thats the benefit of TDD, it is a design methodology. You will find that TDD highlights the most obvious solutions, and that your code will be efficient as a result.
You should be designing around your tests, however, the test itself should not have a bias towards a specific implementation. It should have a specific functional output that needs to be “passed” regardless of whether you use an array, a hashmap or whatever construct needed to achieve the result.
the whole concept of TDD is to work in really small chunks with roughly a 1 - 2 minute turn around between writing the test and writing the code to make the test pass.