Funny test story
-
I hate mock. I mean not in general, in general I don't care I just think they are a waste of time. But I particularly hate them in the case of automated testing. Not only they make you waste time writing code to set them up in each test, but then you are not testing the real thing, you are testing mocks! Now the funny thing is, I had some unit test that validated some functionality as working but it was not working for the user and I was completely puzzled... After writing a little app to test the real thing, turns out I had one insidious mock in my test. Just one. And that was the one thing that worked in the test but failed in the real app! On top of that it was completely unneeded.. the real interface would have worked just as well (or failed, in that case) :o
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I hate mock. I mean not in general, in general I don't care I just think they are a waste of time. But I particularly hate them in the case of automated testing. Not only they make you waste time writing code to set them up in each test, but then you are not testing the real thing, you are testing mocks! Now the funny thing is, I had some unit test that validated some functionality as working but it was not working for the user and I was completely puzzled... After writing a little app to test the real thing, turns out I had one insidious mock in my test. Just one. And that was the one thing that worked in the test but failed in the real app! On top of that it was completely unneeded.. the real interface would have worked just as well (or failed, in that case) :o
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Well, they're unit tests, so you're testing units, not multiple units or entire systems (other tests exist for that). And from the perspective of the unit you're testing it doesn't really matter if IRepository.GetData gets the data from a database, a service or a mock. From the perspective of the test is does matter since the database and service can't be controlled from the test scenario, but a mock can. A mock will always return x when the input is y, a database or service might not. And then the thing you're actually testing can always use value x which should always return value z, which can be asserted.
// Contrived example:
public int AddOneToDbField(IRepository repo)
{
int dbField = repo.GetNumber(); // This should be mocked.
return dbField + 1; // This should be tested and asserted.
}If you want to test your repository you should do stuff like integration testing, although I've also seen unit tests that connect to databases. But if you're testing your mocks you might not be doing it right :-O
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I hate mock. I mean not in general, in general I don't care I just think they are a waste of time. But I particularly hate them in the case of automated testing. Not only they make you waste time writing code to set them up in each test, but then you are not testing the real thing, you are testing mocks! Now the funny thing is, I had some unit test that validated some functionality as working but it was not working for the user and I was completely puzzled... After writing a little app to test the real thing, turns out I had one insidious mock in my test. Just one. And that was the one thing that worked in the test but failed in the real app! On top of that it was completely unneeded.. the real interface would have worked just as well (or failed, in that case) :o
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
you are not testing the real thing, you are testing mocks!
Then you're doing your unit testing wrong.
-
I hate mock. I mean not in general, in general I don't care I just think they are a waste of time. But I particularly hate them in the case of automated testing. Not only they make you waste time writing code to set them up in each test, but then you are not testing the real thing, you are testing mocks! Now the funny thing is, I had some unit test that validated some functionality as working but it was not working for the user and I was completely puzzled... After writing a little app to test the real thing, turns out I had one insidious mock in my test. Just one. And that was the one thing that worked in the test but failed in the real app! On top of that it was completely unneeded.. the real interface would have worked just as well (or failed, in that case) :o
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Maybe the code is mocking you?
CQ de W5ALT
Walt Fair, Jr., P. E. Comport Computing Specializing in Technical Engineering Software
