Category: Techniques

“Web Security Basics” on Martin Fowler’s Site

Security should be at the heart of our profession, but I’m not sure it ever has been. Job interview preparation for developer jobs is largely focused on algorithms, API’s and problem-solving. It’s probably happened somewhere, but I’ve never heard of an interviewer asking a candidate for a typical developer job about how to prevent SQL injection or XSS attacks. I’ve never seen a job posting for an ordinary developer job which mentioned OWASP in the list of desired buzzwords.

That may be changing slowly. The value created by software development has attracted the attention of a lot of thieves who would be happy to steal it. The software craftsperson has a duty to produce software which will discourage and repel those thieves, but good learning materials in the field of security have been scarce. The OWASP site has a great deal of info about security best practices, but it’s not organized in a way which makes it easy to learn.

Martin Fowler’s blog is now hosting an evolving document written by two software security experts which gives a lot of good advice which is also well-organized and well-explained. It’s a bit presumptious for them to call the document “Web Security Basics”, since most web sites do not yet follow all of their recommended practices (such as using only https for all connections), but the article may move a lot of companies to better protect their users’ data and information security. It should be required reading for software craftspeople.

The TestNest Pattern

I discovered the TestNest pattern – the idea of using a suite of nested test classes in order to create a hierarchical organization of tests – in this blog post by Robert C. Martin, but apart from one other article I haven’t found a lot of information online about this technique. So I thought I’d try it out in a sort of hello-world to get a feel for it. As a bonus, I added in some tests using the excellent Zohhak test library which generates automatically nested tests for sets of values via an annotation.

My test class can be found here.

Here are some of the highlights…

The outer class declaration with its JUnit Suite annotations:


@SuiteClasses({ MyExampleClassTest.Method1.class, MyExampleClassTest.Method2.class,

MyExampleClassTest.Calculation1.class, MyExampleClassTest.Calculation2.class})

public class MyExampleClassTest {

One of the nested classes in MyExampleClassTest is called SharedState. It contains the object under test (called underTest) and is the parent of all the other nested test classes (and it also uses a mixin from tdd-mixins-junit4 which gives all its subclasses the ability to call assertions non-statically).

There are 4 nested classes which contain tests – one for each method in the class under test. This seemed like a logical organization, though it’s not what Uncle Bob did in his aforementioned blog post. It might make sense to further subdivide between happy path tests and weird corner case tests (what Uncle Bob called “DegenerateTests” in his example), and there may be better ways to divide tests than along class and method lines (though I would hope that my classes and methods under test are cohesive units of organization).

Using the Suite runner in the parent class doesn’t prevent you from using other runners in the nested classes. Two of the nested classes use the Zohhak test runner:


I intentionally put 2 failures in the tests (one fail() in a normal test and one error in a Zohhak value set) to see what the failures would look like.

Here’s part of what Maven had to say about these failures:

Failed tests: should_fail(org.example.MyExampleClassTest$Method2): intentional failure to illustrate nested test failure messages

should_calculate_cube [-1, 1](org.example.MyExampleClassTest$Calculation2): expected:<[]1> but was:<[-]1>

Here’s what I see in Eclipse’s JUnit sub-window:

Eclipse JUnit run results showing 2 nested errors

This seems like a minor improvement over long, descriptive test method names for quickly getting a feel for where the problem isespecially when there are multiple simultaneous failures. I didn’t have to put the name of the method under test in the test method name, and in the eclipse JUnit runner UI the tests for each method are nicely grouped together.  Zohhak works well with this approach, as well (and seems like a pleasure to use in general for testing calculation results).