Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

With unit tests the domain is quite small, so it's easy. I used Osherove's methodName_conditions_result() scheme and found it very clear.

But with integration tests I feel like it would make a very long name, and what do I put in place of methodName? How do I name integration test classes?

Real world examples of integration test names are very welcome. I hope the answers will also help me to better understand these tests.

share|improve this question
why was this question downvoted (twice)? –  bigstones May 24 '12 at 8:30

4 Answers 4

I take a little different approach with unit and integration tests. I try naming them based on features as much as possible. Then when all the tests pass you can see a list of all the features that work and don't work.

  • canRegisterUser
  • canHandleInvalidInput
  • canRelayDocumentBetweenServers
  • canCreateSchema
  • canLoginUsingWebService
  • canLoginUsingBasicAuth
  • canDeleteDocument
  • canAddDocument

It is not always pragmatic to name the tests this way, but it can be very helpful especially after reading through hundreds of unit and integration tests. The over all encompassing Class name that holds these methods should also be indicative of the features being tested. It will help with organization.

I'd also suggest naming any unit tests for bugfixes with a unique prefix such as bugfix1002 to prove that the bug has been fixed.

share|improve this answer

This was really written to help with unit tests, but perhaps you will find that the same rules apply (more or less) to integration tests:

Check out Seven Steps!

My preference is that whatever you call it, it's really the test suite name (fixture name on our card), the effect you're checking, and the assertion message that need to stand out and make the cause of the error clear. If you find that's easiest with Asherove's naming, then I wholeheartedly endorse that. But maybe the trick is you fill in the "method" part with whatever makes the condition, result, and exception make sense.

I'm happy to see a suite named "MakingADeposit" with a test called "AccountDoesntExist" and an error that says "Expected NonesuchAccount exception - none received."

Alternatively if you don't mind me separating the test suite name with "::", I'm okay with "AccountHandling::MakingADeposit_AccountDoesntExist_ThrowsAnException"

The card also suggests that if you don't have a good name, continue onward and give a better name when one occurs to you (hopefully well before submitting the code to CI).

share|improve this answer

So the problem is that a proper name of functionality is too long for a method name? I know it's awkward to start writing test methods with names like registerAndValidateUnderageUniversityDriverWithCoverageSetA_test() and might ever break compiler rules for long method names (PL/SQL only allows up to 30 characters - I don't know if Java and C# impose such short name limits, but even if they don't it gets pretty unwieldly past a certain point and really really long method names might only be useful for generated code that is read/managed by other generated code). You can try to shorten it to regValUnderageUnivDrvrWCovrgA_test() but that's also really horrible to read. One option I've used that I didn't like but was the best choice at the time was underageUnivDrvr_test_01() and then there was a spreadsheet mapping the method names to a much longer description of the functionality being tested. Ugly, but it worked. You could also document the description of the test in the documentation of the function in the source file, which could be useful because you can generate documentation of the tests directly from the code, instead of mapping back and forth between spreadsheet and code.

share|improve this answer

Integration tests should follow some similar rules to unit tests in that each test should be testing one aspect of a requirement but tests the system as a whole. The class should name the overall thing that is being tested, e.g. "TpcInputValidation" and the naming of the method should reflect expressively what the test is trying to do without being overly wordy, e.g. "shouldRaiseValidationErrorWithBadDates()".

The methods should be testing one concept of the feature and a large number of asserts could indicate otherwise. (Ref. "Clean Code: A Handbook of Agile Software Craftmanship" p. 132, by Robert Martin).

share|improve this answer
Why do you believe "one feature" generally equates to "one assert"? It seems you would want to assert that the system is in the state you expect it to be in, which can be any number of asserts. But I digress because the question is about naming, not how to write an integration test. –  Jeremy Heiler May 22 '12 at 19:00
@Andrew, I didn't say it was a hard rule, but a watching the number of asserts could help with guideline of testing a concept of the feature not necessarily one per method. Keeping them somewhat limited in scope helps identify where the problems are when they fail. But I'll give you that it is not great to say one assert, and I'll edit that out, thanks. –  Turnkey May 23 '12 at 1:47

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.