4 ms·
1. It can be. For something like a standard C# MVC application (Im working on one now) the time taken to spin up Casini or deploy to IIS is far greater then run
by boyter 14y ago
1. It can be. For something like a standard C# MVC application (Im working on one now) the time taken to spin up Casini or deploy to IIS is far greater then running tests. For something like PHP where you are just hitting F5 and TDD can slow you down. As with most things it depends.
2. If you are writing brittle tests you are doing it wrong.
Increasing LOC isn't always a bad thing. If those increased LOC improve quality then I consider it a worthwhile. Yes it can be more maintenance, but we know the cost of catching bugs in development is much cheaper then in production.
Mocking isn't as bad as its been made out to be. Yes you can overmock things (a design anti-pattern), but that should be a sign of code smell and you should be re-factoring to make it simpler. If you cant re-factor and you cant easily mock then consider if you really need to test it. In my experience things that are hard to mock and cannot be re-factored usually shouldn't be tested.
Exception being legacy code, but we are talking about TDD here which usually means greenfield development or else it would have tests already.
Unit testing does NOT promote 100% coverage. People using unit tests as a measure promote this. Sometimes its worth achieving, and sometimes its not. Use common sense when picking a unit test coverage metric. I have written applications with close to 100% coverage such as web-services and been thankful for it when something breaks and I needed to fix it. I have also written applications with no more then 20% over the critical methods (simple CRUD screens). Use common sense, testing simple getters and setters is probably a waste of time so don't do it.
Unit testing isn't all about writing tests. Its also about enforcing good design. Code that's easily testable is usually good code. You don't have to have tests to have testable code, but if you are going to that effort anyway why not add where they can add value and provide you with a nice safety harness?
Most of the issues with unit tests come with people preaching that they are a silver bullet. For specific cases they can provide great value and increase development speed. Personally I will continue to write unit tests, but only where my experience leads me to believe they will provide value.
- andrewflnr 14y agoRe 1, GP is talking about time to develop features, including writing tests, not to actually run the tests.
- Glide 14y agoThat may or may not be valid depending on what one considers "done" in the context of a project. My team considers a feature done when it goes through QC and business analysis. I personally find it nice to just hit a couple of hotkeys instead of working through the application itself in order to test functionality. It does save me time because I want to ensure that the feature works and I have to devote less cycles to fix some small thing I missed when running the real app as opposed to tests.
- boyter 14y agoAs am I. In my sample app its faster to write the feature and the tests and run those then to spin everything up and see it working. I have had the same experience in large Java applications as well.