views:

74

answers:

2

The title is probably not very clear. I have the following example in mind:

an Authenticator object authenticates a user using credentials. It returns a AuthResult object. This AuthResult object says the authentication succeeded, or that it failed (and if so, why it failed, eg username not found).

How can I phrase this in a test? 'testShouldReturnAuthObjectWithStatusSuccessOnValidLogin'?

+4  A: 

testValidLoginIsSuccessful or testIsSuccessfulOnValidLogin seems good enough for me.

For error tests, you could use something like testGetsCustomMessageOnUserNotFound

You should avoid putting implementation details in the method name.

Samuel Carrijo
Let's say this Authenticator uses some other classes with specified responsibilities to do some work (eg connect to a database). If I write tests for those classes, does that mean I'm giving away implementation details of the 'complete-authentication-package'?
koen
No, I'm just talking about the method name. And you should probably mock these other classes if you want to unit test it. Then you test those other classes in isolation, and see if they work isolatedly
Samuel Carrijo
A 'complete-authentication-package' would be an integration test. You would test if these classes are well wired and if the process as a whole works. In this case, it is even more recommended that its name is not implementation specific.
Samuel Carrijo
+2  A: 

Without seeing how these tests are implemented, it seems from the naming that the observations are over-packed.

If this test fails, you'll have to do some digging to know if it is because (a) no AuthResult object was returned, or (b) status was not "success," and further, was there no AuthResult because the Authenticator never connected to the database or do some other required action?

I'd name the fixture When_told_to_authenticate_with_valid_credentials and then separate the assertions into two different observations:
1. should_return_an_AuthResult
2. should_be_successful

If you mock out those other classes as Samuel rightly suggested, you can further stipulate that the Authenticator is behaving as you expect:
3. should_connect_to_the_database
4. etc.

Jay
Isn't should_return_an_AuthResult an implemenation detail?
koen
Yes, it is an implementation detail. I don't agree with the premise that implementation details should not be included in the names of TEST methods, because (1) it is precisely the implementation you are concerned with and are testing when focusing on behaviour (rather than state), (2) the method name should therefore clearly reflect exactly what is passing or failing, and (3) the test assemblies are not published or deployed.
Jay