In the first case, when I check the same thing for different input, I would either create a helper method
def assert_obtained_account_is_the_same_as_we_searched_for(self, account_number):
self.assertEquals(account_number, self.service.get_customer_for(account_number).account_number)

and use that inside the test – simply to respect the single responsibility principle, and to remove the how from the test, so they can focus on the what

Could you elaborate why you consider the second case bad? E.g.: when asserting against an object’s default values, I would write such tests and I don’t consider it bad

P.S.: and sorry for accidentally writing the code in Python instead of Java :)

I don’t have a problem with having multiple simple asserts with inlined values, though.

So, for me, this is rather good:

public void can_obtain_a_customer_by_account_id() throws Exception {
assertEquals(“ABC99", serviceImpl.getCustomer(“ABC99").getAccountId());
assertEquals(“X", serviceImpl.getCustomer(“X").getAccountId());
assertEquals(“1", serviceImpl.getCustomer(“1").getAccountId());
}


While this is (a little) bad:

public void can_obtain_a_customer_by_account_id() throws Exception {
Customer customer = serviceImpl.getCustomer(“ABC99");

assertEquals(“ABC99", customer.getAccountId());
assertEquals(“John", customer.getName());
}


@Test
public void can_obtain_a_customer_by_account_id() throws Exception {
obtainedAccountId = serviceImpl.getCustomer(“ABC99″).getAccountId()

assertEquals(“ABC99″, obtainedAccountId);
}

here, the Arrange part is in the setUp(Fixture), thus implicit. I know you don’t like local variables, but it helps when there are multiple asserts (which might be of course a single logical assert) and you want to use plain JUnit and not introduce a new framework that has Facts/Observations).

Oh, another thing: I have found that I do not like to apply the same rules when writing test code and production code. Particularly, I do not believe that the DRY principle applies as much in test classes. However, the readability is a lot more important in the tests than it is in the production code.
Several people I’ve talked to did seem to dislike this approach, though.

private Searcher searcherWithSomeValue = new Searcher( “some value” );
private Searcher searcherWithSomeOtherValue = new Searcher( “some other value” );

I think this is mostly because I want my tests to read like little stories:

assertThat(searcherWithSomeValue, not(is(searcherWithSomeOtherValue)));

I think the following feels less natural:

assertThat(toTest, not(is(toCompare)));

However, in my production code, I would probably use names similar to the ones you suggest.

Just another idea about the class that the builder methods live in; and trying to do DRY. My preference is to make such methods public and static, and put them in the test class for whichever type they are most closely related to. In your example, they’d be in the UserTest class. Public is OK, since they only ever end up in the test version of the build, not the production build.

That way, when I come to write any test class that does some building on the User class, I know that I’m likely to find the builder method in UserTest. So I put the right static import at the top of my test class, and end up with the same concise, readable code that you’ve exhibited here.

Just a minor point – whether “searcher” is a field or a local variable (and like you, I prefer it to be a field), there’s no point in having a variable name which is just the same as the name of its type (minus the initial capital) – you may as well just call it x.

In my opinion, a variable name should reflect what that variable is for. This really helps to understand code when you come back to it several months later. This idea applies to all code, of course; but in the case of unit tests, if the variable references the object to test, I prefer to call it toTest. Then, if you need two Searcher objects for any reason (maybe you’re testing equals() or compareTo()), then the second one could be toCompare.

private Searcher toTest = new Searcher( “some value” );
private Searcher toCompare = new Searcher( “some other value” );