I can see the point in unit testing - it's a tool that's useful for testing specific things. However, I see far too often tests written to check that a call to an MVC controller returns a specific view. I mean, it's a bleedin' MVC view controller, it's going to return a view and it's going to be bleedin' obvious if it's not the right one!! But no, developers still want to write 50+ unit tests on every action on every controller.
Then there's DI.. great for testing, but does anyone ever stop and think "how many classes are getting instantiated on every hit of each request to my site?" - I doubt very many are. Loose coupling makes unit testing possible but 99.9999% of you application's lifetime isn't going to be spent under test, is it? It's more CPU usage, more memory usage, slower applications out there in production.. The worst thing is that so many developers assume that because all the unit tests pass, their application is working! It isn't, at least until it's been manually confirmed that it's working.
My take on it is: unit test what absolutely needs to be unit tested and no more.
Ah, I see you have the machine that goes ping. This is my favorite. You see we lease it back from the company we sold it to and that way it comes under the monthly current budget and not the capital account.
It is a big effort to get a good rate (80%+) and have it with usefull tests.
I for my self am still stuck on the 10% because i don't have the time to do further unit tests. But it still is a measurment for me since i can surely say those 10% are working if the tests don't fail.
I guess it's an issue most people have. I either don't have enough time to write proper tests or you don't have the knowledge to do good tests. I still need to get into a mocking framework to be able to test my methods where db querry are executed
Quoting CPallini in Klingon mode active:
Testing is for kids, deploying to line server strengths your character
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
I do not believe that we can slap on a number to ensure that tests are actually meaningful. I have worked in places where we had to make sure that 80% or more coverage was required. Getting to that number, honestly, is very easy. Getting to that number with meaningful tests, may or may not be.
So, yes we should look at the coverage but no that does not tell how well we have unit tested the code.
Last Visit: 31-Dec-99 19:00 Last Update: 30-Jan-23 15:02