• @Michael Stum: Given the following test:

    var someString = "moo";

    TestDriven.Net gives me:

    TestCase 'SomeTestCase'
    Expected: not null and not and "foo" and not "bar" and String starting with "f"
    But was: "moo"

  • I use the new asserts because they're typically clearer than the old ones.

    E.g. compare:
    // which is the expected value? I can never remember
    Assert.AreEqual(one, two);

    // but this is 100% clear to me
    Assert.That(one, Is.EqualTo(two));

    On the other hand, I usually don't see the point in chaining together lots of calls in one assert; it's often just several asserts masquerading as one which is often a warning sign that the test is doing too much.

  • @Bjoern: Testing one thing doesn't necessarily mean that you should only check one thing. Often does, but sometimes you actually need to check more things to make something is valid.

    And in that case I would prefer to have them in one assert, using the fluent api instead of two regular asserts. The reason is, like I showed in my previous comment (the TestDriven.net output) that I will see the all the expectations and why it failed them. Using regular, multiple asserts I would only see the first assert.

    @Mark: I have the same experience. I tend to mess up the order in the AreEqual (expected vs actual, first or last). And when I do get it wrong (which happens), the test output from a failing test can be very confusing, hehe.

    @Roy: You should get some code syntax stuff or something here. That last comment of mine looks awful :p

  • I started using the "new" asserts a while ago, since they read better than the "old" asserts. I had no idea you could chain the conditions, though. Will have to try it, it could make tests rather...interesting.

  • @Svish,

    you say "but sometimes you actually need to check more things to make something is valid. "

    ok, yes, but in Roys book, the art of unit testing, he says that the verbosity of individual tests are worth while. Splinting each into its own test is a good idea, however, if you dont want to go that far, you can test using the [ROW] and provide the different input via that. Iv only started reading his book, but he also mentions that if you have multiple tests that test the same thing then its duplication, and you will have to maintain all those tests, and thats a problem, esp when they change, test things once and test it right, you need to have trust worthy tests rather then muultiple tests that each only test a part of it..

    anyways, what do i know :)

  • I like the AssertionHelper.Expect entry point that comes from inheritance of the AssertionHelper base class. Adds a bit less verbosity instead of Assert.That

    I also like to use a TestDelegate declared in the action "section" of my test and named action:
    TestDelegate action = () => some code;

    Then I follow this with inline exception checks:

    Assert.That(action, Throws.TypeOf());

    This way I still keep the three AAA sections even with exception checking :)

  • @Z: I've read his book too, and I do agree ;) But say for example that you have a TryParse kind of method.

    static bool TryParseSomething(string subject, out SomeType result) { ... }

    To test that this method really succeeds for some certain input, you first have to check that the method in fact returns true, and then that the result is what you expected. To split this into two test methods, I would just find ridiculous...

  • ... what do you think Roy?

  • I think multiple asserts are OK, as long as they are all part of the same "logical concept" so, if one of them fails, you don't care about the rest.
    so, for example
    checking multiple props of the same object instance might be OK, but checking props of multiple objects is really testing two things.

    regardless, you can use the fluent API without doing multiple asserts, which is what I was asking.

  • I dont do multiple asserts, it makes the tests unclear, how to name a test with multiple asserts, etc. It's possible through the language, but I think it's a bad idea

  • Thanks Roy!

    Yes that makes sense as it mitigates the cons you mentioned in your book namely figuring out which part failed and why.

    Btw, I love your book, I tried to find other books by you but was sadly disappointed, are you considering or are you writing any new ones?


Comments have been disabled for this content.