Hot answers tagged

8

When you write two tests at once, and start implementing code to make the first test pass, you cannot run the whole test suite and get a "green" result, because the second test will still fail. You can look at the detailed output of your unit test framework and check visually that exactly the test failed which you expected, of course, but that has a ...


6

The reason for staying with one failing unit test at a time is focus. When you have that single failing unit test, you know exactly what to work on; you know what part of the code to think about; you know what problem you are solving immediately. If you allow yourself to write more tests as you work on solving one problem, pretty soon you are solving two - ...


4

Every one of those outcomes that you described are valid testing scenarios. The way you know that is that each behavior is tied to a different outcome. That makes each one a prime candidate for testing. From a Cyclomatic Complexity point of view, the fact that there are different outcomes for each test corresponding to different program states almost ...


4

It should be pointless. But you should be making sure handler calls what validator needs called. For unit testing you should be testing in isolation. That means you'll need a stub (or mock) validator to hand to handler when you test handler. You don't check validator business logic when testing handler. You test that handler calls validator (in this ...


2

Obviously I want to make sure that the validator is called when the handler does its thing Then mock the validator and test that it is called with the right parameters. No need to test the validator itself twice. On a related note, unit tests have their true value in test driven development. It sounds like you are writing the tests after the code ...


1

There's always a trade-off between creation and testing, I could create a perfect product, just come back in 10 years and it'll be ready.. and no manager will ever accept that estimate (or the cost :) ) So you have to be pragmatic, unit tests do not catch all bugs, so you should not try to create unit testing environment that is 100% perfect with 100% code ...



Only top voted, non community-wiki answers of a minimum length are eligible