On the subject of names, changing the case of abbreviations doesn't help readability much. How about HTMLLinkRewriterTest rather than HtmlLinkRewriterTest? CamelCase is just a guide.
Not really on topic, but this example reminds you that it's always good style to use words like "has" or "is" or "does" when dealing with anything remotely boolean. Though I always try to avoid negations like "not" (e.g. "DoesNotRewrite") and rather use positive names (dunno, "void test(!doesRewriteImage...)" or "testDoesUseStableImageLinks" or whatever). But of course I'm just saying this in general, not applicable to this snippet.
So where are the real blog posts on testing, data driven practices, extensiblity, deployemnt automation..? I really hope this isn't the best stuff Google has for testing advice.
Linux 2.6.20 got released yesterday. One of the "noteworthy" news is fault injection. Any of you guys ever used this for testing purposes? I think it could be a great aproach!
Something seems wrong here to me. Assertions about what a class or function should do or not do should be, well, assertions. Tests are attempts to make a class violate its contract; assertions (or postconditions, if you prefer) check that the contract is not being violated.
Naming test cases after aspects of the class contract implies a one-to-one relationship between test cases and postconditions. This is arbitrary and often wrong. Every test case should pass every assertion without triggering it, and there may be many more parts of the input space that need special testing than there are postconditions.
Exactly what a class should do with its assertions in production is an engineering decision, but they belong in the source code and should be checked for _every_ test case. Tests should be generated and named according to an understanding of the input space, not the class contract.
I wish I could print and put this on our toilet, but I work on a bank ;-(
ReplyDeleteOn the subject of names, changing the case of abbreviations doesn't help readability much. How about HTMLLinkRewriterTest rather than HtmlLinkRewriterTest? CamelCase is just a guide.
ReplyDeleteI love self-documenting code. :)
ReplyDeleteNot really on topic, but this example reminds you that it's always good style to use words like "has" or "is" or "does" when dealing with anything remotely boolean. Though I always try to avoid negations like "not" (e.g. "DoesNotRewrite") and rather use positive names (dunno, "void test(!doesRewriteImage...)" or "testDoesUseStableImageLinks" or whatever). But of course I'm just saying this in general, not applicable to this snippet.
So where are the real blog posts on testing, data driven practices, extensiblity, deployemnt automation..? I really hope this isn't the best stuff Google has for testing advice.
ReplyDeleteThe TestDox functionality of PHPUnit makes this "agile documentation through test names" accessible, as does its role model, the TestDox extension for JUnit.
ReplyDeleteI'd like to know more how a class in IntelliJ with the TestDox plugin gives an overview of the test.
ReplyDeletePerhaps you guys can elaborate more. I am not feeling very motivated.
Linux 2.6.20 got released yesterday. One of the "noteworthy" news is fault injection.
ReplyDeleteAny of you guys ever used this for testing purposes? I think it could be a great aproach!
Something seems wrong here to me. Assertions about what a class or function should do or not do should be, well, assertions. Tests are attempts to make a class violate its contract; assertions (or postconditions, if you prefer) check that the contract is not being violated.
ReplyDeleteNaming test cases after aspects of the class contract implies a one-to-one relationship between test cases and postconditions. This is arbitrary and often wrong. Every test case should pass every assertion without triggering it, and there may be many more parts of the input space that need special testing than there are postconditions.
Exactly what a class should do with its assertions in production is an engineering decision, but they belong in the source code and should be checked for _every_ test case. Tests should be generated and named according to an understanding of the input space, not the class contract.
Weekly turned montly? Where's the next installment? Awaiting...
ReplyDeletesimilar to testdox, there is also a spec plugin for nose (a python test runner) that just came out.
ReplyDelete