tdd

I have a good grasp of unit testing, DI, mocks, and all the design principal goodness required to have as close to full code coverage as humanly possible (single responsibility principal, think 'how will i test this' as I code, etc...). My most recent app, I did not code doing true TDD. I kept unit-testing in mind as I coded, and wrote my tests after writing the code, refactoring, etc.. I did TDD when it was 'easy' to do... however I did not have as good of a grasp as I do now... That was the first project I made full use of DI, mocking frameworks, etc, and the first which had full code

I've read (and re-read) Martin Fowler's Mocks Aren't Stubs . In it, he defines two different approaches to TDD: "Classical" and "Mockist" . He attempts to answer the question " So should I be a classicist or a mockist? ", but he admits that he has never tried mockist TDD on "anything more than toys." So I thought I'd ask the question here. Good answers may repeat Fowler's arguments (but hopefully more clearly) or add arguments that he didn't think of or that others have come up with since Fowler last updated the essay back in January 2007. I don't think you need to choose one over the other.

While unit-testing seems effective for larger projects where the APIs need to be industrial strength (for example development of the .Net framework APIs, etc.), it seems possibly like overkill on smaller projects. When is the automated TDD approach the best way, and when might it be better to just use manual testing techniques, log the bugs, triage, fix them, etc. Another issue--when I was a tester at Microsoft, it was emphasized to us that there was a value in having the developers and testers be different people, and that the tension between these two groups could help create a great product

You may think this question is like this question asked on StackOverflow earlier. But I am trying to look at things differently. In TDD, we write tests that include different conditions, criteria, verification code. If a class passes all these tests we are good to go. It is a way of making sure that the class actually does what it's supposed to do and nothing else. If you follow Bertrand Meyers ' book Object Oriented Software Construction word by word, the class itself has internal and external contracts, so that it only does what its supposed to do and nothing else. No external tests required

I'm working on a Spring MVC project, and I have unit tests for all of the various components in the source tree. For example, if I have a controller HomeController , which needs to have a LoginService injected into it, then in my unit test HomeControllerTest I simply instantiate the object as normal (outside of Spring) and inject the property: protected void setUp() throws Exception { super.setUp(); //... controller = new HomeController(); controller.setLoginService( new SimpleLoginService() ); //... } This works great for testing each component as an isolated unit - except now that I have a

I'm the only developer in my (very small) company and I'm about to start on a medium sized ASP.NET web application for said company. I'm trying to figure out if I should learn Test Driven Development (TDD) and implement it in this application. I need to start developing our new application shortly and I'm worried about testing. I've programmed for many years but have never done any unit testing. I've read numerous online resources regarding TDD but I'm unsure whether I'll have a 'good enough' grasp on it to make it effective in the application. It depends on where your priorities lie. If you

There are lots of mocking frameworks out there for .Net. There is no clear winner that has superseded the others in every way. The leading mocking frameworks also have many different styles of usage. The time it takes to learn all of the mocking frameworks well enough to decide which to use is unreasonable. I don’t believe that we have yet reached a stage that we can talk about the best mocking framework. So what questions should I be asking, both about the project, and about myself, to help decide on the best mocking framework to use, in a given case? It would also be useful to know why you

I honestly don't see the difference between BDD and TDD. I mean, both are just tests if what is expected happens. I've seen BDD Tests that are so fleshed out they practically count as TDD tests, and I've seen TDD tests that are so vague that they black box a lot of code. Let's just say I'm pretty convinced that having both is better. Here's a fun question though. Where do I start? Do I start out with high level BDD tests? Do I start out with low level TDD tests? I honestly don't see the difference between BDD and TDD. That's because there isn't any. I mean, both are just tests if what is