Is Assert.Fail() considered bad practice?

前端 未结 14 1158
面向向阳花
面向向阳花 2021-01-31 07:20

I use Assert.Fail a lot when doing TDD. I\'m usually working on one test at a time but when I get ideas for things I want to implement later I quickly write an empty test where

14条回答
  •  天涯浪人
    2021-01-31 07:45

    I think you should ask yourselves what (upfront) testing should do.

    First, you write a (set of) test without implmentation. Maybe, also the rainy day scenarios.

    All those tests must fail, to be correct tests: So you want to achieve two things: 1) Verify that your implementation is correct; 2) Verify that your unit tests are correct.

    Now, if you do upfront TDD, you want to execute all your tests, also, the NYI parts. The result of your total test run passes if: 1) All implemented stuff succeeds 2) All NYI stuff fails

    After all, it would be a unit test ommision if your unit tests succeeds whilst there is no implementation, isnt it?

    You want to end up with something of a mail of your continous integration test that checks all implemented and not implemented code, and is sent if any implemented code fails, or any not implemented code succeeds. Both are undesired results.

    Just write an [ignore] tests wont do the job. Neither, an asserts that stops an the first assert failure, not running other tests lines in the test.

    Now, how to acheive this then? I think it requires some more advanced organisation of your testing. And it requires some other mechanism then asserts to achieve these goals.

    I think you have to split up your tests and create some tests that completly run but must fail, and vice versa.

    Ideas are to split your tests over multiple assemblies, use grouping of tests (ordered tests in mstest may do the job).

    Still, a CI build that mails if not all tests in the NYI department fail is not easy and straight-forward.

提交回复
热议问题