Discussion of testing theory and practice, including methodologies (such as TDD, BDD, DDD, Agile, XP) and software - anything to do with testing goes here. (Formerly "The Testing Side of Development")
I've written a test case which when run makes an unknown number of assertions as the test uses some arbitrary data in order to be a little fairer/well-covered:
Bceuase of the fact it's a bit random, the number of assertions made varies (massively) and thus, the results of the test case always display different numbers. If you keep refreshing the page you just keep seeing a green bar with changing numbers. Would this put people off trusting the test?
Hmm... come to think of it, as simple pattern would probably suffice, although the failure details wouldn't be as clear.
I agree with Feyd. Furthermore, the randomization does you no good because, in the unlikely case a test case does fail, you have no way of getting the random data!
I generally use input randomization for benchmarking.
Ambush Commander wrote:I agree with Feyd. Furthermore, the randomization does you no good because, in the unlikely case a test case does fail, you have no way of getting the random data!
I generally use input randomization for benchmarking.
Exactly my sentiments. I would feel horrible if I found my test failed for whatever reason because of random data, because I would be unable to replicate that failure every time (which defeats the purpose of testing).
That's a really long test method. Can you break it into smaller pieces?
yours, Marcus
I should listen to you, being the author and all that stuff (thanks!)
But... it's not as if the test does a lot of stuff, it's just long because I wanted to do it with a few different values for a bit of variation. Perhaps the assertions which happen after some encoding has been done can be moved into a new method. Breaking it into smaller methods feels a bit pointless (with the exception of the encoding part) when really, that whole method is just testing that a line-wrap feature is working
It seems about right for what it does, Marcus just might mean a short method is easier to digest. Since tests can be documentation, the shorter and more concise an individual test is (even it's only decomposing small functional unit to private methods) the easier it is to understand. It's a fairly common internal refactoring...
In this case you have 4 subunits (calls to new MimeExtension()). Each differs by the encoding used. So four separate tests with four separate methods.