Comments on: One assertion per test—always?

By: PHP Planet — One assertion per test—always?

PHP Planet — One assertion per test—always? — Fri, 20 Feb 2009 14:06:06 +0000

[...] Read more at One assertion per test—always? [...]

By: Logosfera

Logosfera — Wed, 18 Feb 2009 07:08:53 +0000

I’m using simpleTest for unit testing and a test is usually a class. Now if you develop your test class PERFECTLY you and up with X tests with exactly X assertions. But practically this situation is no different than having 1 test with X assertions because the assertion tells you what you’re testing and the test are there just as markers (which can be written by comments). If the PERFECT way of writting tests is the same as the WORST way of writting tests there must be something wrong with a “perfect” test.

By: Mathias

Mathias — Mon, 16 Feb 2009 14:54:51 +0000

I agree that tests should be small and atomic and should only test one “event” or one “change” or however to call it, but I don’t think using only one assertion is a good way to archieve this. Escpecially when you want to prevent hidden “assertTrue(true)” you’ll need multiple assertions to make the test more robust.

By: Toby

Toby — Mon, 16 Feb 2009 09:07:45 +0000

That is true, yes. As you said: A lot of work for trivial gain. I just dislike this “just to do it mantra-like correct” way of doing things.

To teach unexperienced testers how to write tests, the base rule must be “one assertion per test”. For experienced testers, who know how to test properly and who re-check frequently if they did not become lazy, this is just an efficiency waddle.

By: dagfinn

dagfinn — Mon, 16 Feb 2009 07:54:55 +0000

I agree, although theoretically at least you could have a setup to create the object and then test different parts of it in different methods. That might be a lot of work for trivial gain, though. Alternatively, you can create custom assertions.

By: Toby

Toby — Sun, 15 Feb 2009 20:55:51 +0000

It’s pretty obvious that you sometimes need multiple assertions per test, since you need to assure that different parts of an object state have changed. That either means that you need to artificially create the very same object state in a different instance (which is not always possible) or you need multiple assertions, to ensure all expected parts of the object state changed and other parts did not.

Of course, such scenarios do not fit the typical “dice roling game” example used to illustrated unit testing.