Good one, certainly it helps to trace out the left over requirements, moreover if Priority of test cases is also added e.g., "descriptive_name_Priority01", it gives the added advantage in identifying the test cases to be run on basis of priority whenever required.
Very well-written article. I personally use a unit test naming pattern along the lines of:
public void [FUT]_When[SomeContextOrScenario]_Returns[(or Updates..., or Affects..., etc.)SomeValueOrResult]() { /* ... */ }
Please note: - This example is in C#, with bracketed "parameters" and alternatives in parentheses.
- In this example, FUT is the "function under test" (the overall test fixture, or "[TestClass]" will correspond/relate to the SUT, or "system under test"). I've found this part of the convention to be extremely useful, as it allows me to select a sub-section of tests, as applicable to a particular function, by simply using [Shift + left-click]. This is possible because many "Test Explorer" implementations alphabetize unit tests.
- People are often upset initially by the underscores, and sometimes resist their inclusion, but those characters help me identify the segregated responsibilities of the test name (what requirements the name must satisfy, as discussed in this article). Once, an open-minded lead developer asked me to remove the underscores (on a "for now..." basis), and then come back and actually SUGGESTED underscores, but under strict guidelines, for readability. :-) (That's how I feel more lead developers should approach conflicting ideas from their teammates. He even credited me when formalizing his suggestion. Thanks, Jeff!)
Thanks for this well-presented information and I look forward to future installments of TotT. I apologize if anything in this post is "superfluous" or "noise". I get excited about large companies embracing topics dear to me.
Good one, certainly it helps to trace out the left over requirements, moreover if Priority of test cases is also added e.g., "descriptive_name_Priority01", it gives the added advantage in identifying the test cases to be run on basis of priority whenever required.
ReplyDeleteVery well-written article. I personally use a unit test naming pattern along the lines of:
ReplyDeletepublic void [FUT]_When[SomeContextOrScenario]_Returns[(or Updates..., or Affects..., etc.)SomeValueOrResult]()
{
/* ... */
}
Please note:
- This example is in C#, with bracketed "parameters" and alternatives in parentheses.
- In this example, FUT is the "function under test" (the overall test fixture, or "[TestClass]" will correspond/relate to the SUT, or "system under test"). I've found this part of the convention to be extremely useful, as it allows me to select a sub-section of tests, as applicable to a particular function, by simply using [Shift + left-click]. This is possible because many "Test Explorer" implementations alphabetize unit tests.
- People are often upset initially by the underscores, and sometimes resist their inclusion, but those characters help me identify the segregated responsibilities of the test name (what requirements the name must satisfy, as discussed in this article). Once, an open-minded lead developer asked me to remove the underscores (on a "for now..." basis), and then come back and actually SUGGESTED underscores, but under strict guidelines, for readability. :-) (That's how I feel more lead developers should approach conflicting ideas from their teammates. He even credited me when formalizing his suggestion. Thanks, Jeff!)
Thanks for this well-presented information and I look forward to future installments of TotT. I apologize if anything in this post is "superfluous" or "noise". I get excited about large companies embracing topics dear to me.
Sincerely,
Mike Manard
Name of test only, since formatting seems a bit off above...
ReplyDelete[FUT]_When[SomeContextOrScenario]_Returns[(or Updates..., or Affects..., etc.)SomeValueOrResult]()
Thanks for sharing.
ReplyDelete