D.S

langrsoft.com

programming – Langr Software Solutions

programming – Langr Software Solutions programming – Langr Software Solutions Consulting and Training for Software Teams The Compulsive Coder, Episode 7: Please AAA Q. What behavior does the following JUnit test describe? (In other words, what’s an appropriate name for the test?) MockInitialContext mic = MockInitialContextFactory.getContext(); mic.map.put(ClassicConstants.JNDI_CONTEXT_NAME, "tata"); LoggerFactory.getLogger(ContextDetachingSCLTest.class); ContextJNDISelector selector = (ContextJNDISelector) ContextSelectorStaticBinder.getSingleton().getContextSelector(); Context context = selector.getLoggerContext(); assertEquals("tata", context.getName()); System.out.println(selector.getContextNames()); assertEquals(2, selector.getCount()); Maybe it helps, just a bit, if I tell you that the test name is testCreateContext. Why must I spend time reading through each line of a test like this to understand what it’s really trying to prove? The test designer might have made the central point of the test obvious, by visually chunking the test into its Arrange-Act-Assert (AAA) parts: MockInitialContext mic = MockInitialContextFactory.getContext(); mic.map.put(ClassicConstants.JNDI_CONTEXT_NAME, "tata"); LoggerFactory.getLogger(ContextDetachingSCLTest.class); ContextJNDISelector selector = (ContextJNDISelector) ContextSelectorStaticBinder.getSingleton().getContextSelector(); Context context = selector.getLoggerContext(); assertEquals("tata", context.getName()); System.out.println(selector.getContextNames()); assertEquals(2, selector.getCount()); Well, I think that’s right at least, given what we know. (Yes, the word “test” in the name duplicates the requisite @Test annotation. And yes, there are other problems with the test, e.g. printing anything to the console. But it’s excruciatingly simple to first ensure the structure of a test is clear.) Standards are only that if they are constantly adhered to. The Compulsive Coder, Episode 6: this Duplication is Killing Me A few months ago, I got caught up in a series of contentious debates about duplication in test code. I’m the sort who believes that most of our design heuristics–simple design in this case–fall victim to the reality of the pirate’s code: “The code is more what you’d call ‘guidelines’ than actual rules.” Which is OK by me; rules are made to be broken. Image courtesy drivethrucafe; license Unit tests are different beasts than production code. They serve a different purpose. For the most part, they can and should follow the same standards as production code. But since one of their primary purposes is to provide summary documentation, there are good reasons to adopt differing standards. (I solicited some important distinctions on Twitter a few months ago; this will be fodder for an upcoming post.) With respect to Beck’s four rules of simple design, many have contended that expressiveness slightly outweighs elimination of duplication, irrespective of being production code or tests. With production code, I’m on the fence. But for tests? The documentation aspect of tests is more relevant than their adherence to OO design concepts. Yes, duplication across tests can cause some future headaches, but the converse–tests that read poorly–is a more typical and bigger time-waster. Yes, get rid of duplication, absolutely, but not if it causes the readability of the tests to suffer. My dissenting converser was adamant that eliminating duplication was king, citing Beck himself in Test Driven Development by Example (2002), on page one, no doubt: Step four in the rhythm of TDD says you run all the tests, and step five, “Refactor to remove duplication.” In that summary of steps, Beck suggests no other reasons to refactor! I can understand how a literalist-slash-originalist might be content with putting their foot down on this definition, never mind that “refactoring” has a broader definition anyway, never mind Beck’s simple design to the contrary, and never mind 14 years passage in which we’ve discussed, reflected, and refined our understanding of TDD. Why a contentious debate? The dissenter was promoting a framework; they had created some hooks designed to simplify the creation tests for that framework. A laudable goal, except for the fact that I had no clue what the tests were actually proving. That just wads my undies. Where am I going with all this? Oh yeah. So as I watched the dissenter scroll through some of their tests & prod code onscreen, I noted this repeated throughout: public void doSomeStuff() { this.someField = someMethod(); int x = this.someField + 42; // etc. } Apparently their standard is to always identify field usage by scoping it with this. (I bit my lip, because at that point I was weary of the protracted debate, and figured I could write about it later. Here I am.) &#8220