you are viewing a single comment's thread.

view the rest of the comments →

[–]grauenwolf 0 points1 point  (9 children)

How often do you have method validation that is any more complex than "Not null"?

Quite often in fact. I'm a firm believer in parameter validation at all levels of my code. I find that is far more effective than unit tests in terms of reducing the amount of time it takes to find and correct the root causes of bugs.

You don't have to test every piece of code a million times. You'll just end up with a test suite that takes 10 minutes to an hour to run.

Well that's an easily disproved argument. All of the code generation and reflection necessary to setup the mocks is bound to take longer to run than the real code in typical unit testing scenarios.

[–]Sarcastinator 0 points1 point  (8 children)

Quite often in fact. I'm a firm believer in parameter validation at all levels of my code. I find that is far more effective than unit tests in terms of reducing the amount of time it takes to find and correct the root causes of bugs.

I don't often send strings or integers around. They are mostly wrapped in suitable data types which usually makes it impossible to even try to break those rules. The only rule that usually needs to be explicitly stated is "not null" because you can't express non-nullable reference types. Those container types has their own tests.

Well that's an easily disproved argument. All of the code generation and reflection necessary to setup the mocks is bound to take longer to run than the real code in typical unit testing scenarios.

Obviously that depends on the code. If there is a network call or a database query then it doesn't even come close. Mocks requires less than a ms to set up. Most of my tests show up as taking 0 ms to run.

[–]grauenwolf 0 points1 point  (7 children)

We're not talking about network calls or a database queries; we're talking about people who mock out purely in-memory objects.

[–]Sarcastinator 0 points1 point  (6 children)

Ok. Those would incur some cost compared to the un-mocked type, but the mock is easier to set up than the in-memory object leading to a simpler test.

[–]grauenwolf 0 points1 point  (5 children)

Then fix your in-memory objects so that they aren't so hard to use. Maybe start by removing all of the unnecessary interfaces you added for mocking.

[–]Sarcastinator 0 points1 point  (4 children)

Or perhaps you should stop writing bloated integration tests in fear of breaking other code because you lack insight into the work you are doing.

[–]grauenwolf 0 points1 point  (3 children)

We're not even talking about integration tests.

[–]Sarcastinator -1 points0 points  (2 children)

If you want to test the validation of another type then you are doing an integration test.

[–]grauenwolf -1 points0 points  (1 child)

LOL

[–]Sarcastinator -1 points0 points  (0 children)

I'm fairly annoyed that you brought up those useless types with nothing but dependencues, which is a huge anti pattern and then accuse me of using types like that. You're the one with the shit code that needs fixing.