Skip to main content
Code Review

Return to Answer

edited body
Source Link
Cristian Lupascu
Cristian Lupascu
  • 1.4k
  • 1
  • 9
  • 18

I find that Roy Osherove's test naming convention is easy to apply and provides suggestive names for the test methods.

Roy proposes that the test method names should be composed of three parts:

  • MethodName (or PropertyName, as in our case)
  • StateUnderTest (a brief description of the scenario being tested)
  • ExpectedBehavior

Following this convention, the methods in the DoorTest class could be named:

  • IsVirtual_NameStartsWithLetterOtherThanV_ReturnsFalse
  • IsVirtual_NameStartsWithLetterV_ReturnsTrue

Following a convention like this can provides consistency and makes it easy to use and maintain the test code.

Also, having the three elements delimited by underscores provides good readability.: In case a test fails, with only a glance, you are easily able to grasp all relevant information about the failure: what component failed? what was the failure scenario? what is the expectancy that was not met?

I find that Roy Osherove's test naming convention is easy to apply and provides suggestive names for the test methods.

Roy proposes that the test method names should be composed of three parts:

  • MethodName (or PropertyName, as in our case)
  • StateUnderTest (a brief description of the scenario being tested)
  • ExpectedBehavior

Following this convention, the methods in the DoorTest class could be named:

  • IsVirtual_NameStartsWithLetterOtherThanV_ReturnsFalse
  • IsVirtual_NameStartsWithLetterV_ReturnsTrue

Following a convention like this can provides consistency and makes it easy to use and maintain the test code.

Also, having the three elements delimited by underscores provides good readability. In case a test fails, with only a glance, you are easily able to grasp all relevant information about the failure: what component failed? what was the failure scenario? what is the expectancy that was not met?

I find that Roy Osherove's test naming convention is easy to apply and provides suggestive names for the test methods.

Roy proposes that the test method names should be composed of three parts:

  • MethodName (or PropertyName, as in our case)
  • StateUnderTest (a brief description of the scenario being tested)
  • ExpectedBehavior

Following this convention, the methods in the DoorTest class could be named:

  • IsVirtual_NameStartsWithLetterOtherThanV_ReturnsFalse
  • IsVirtual_NameStartsWithLetterV_ReturnsTrue

Following a convention like this can provides consistency and makes it easy to use and maintain the test code.

Also, having the three elements delimited by underscores provides good readability: In case a test fails, with only a glance, you are easily able to grasp all relevant information about the failure: what component failed? what was the failure scenario? what is the expectancy that was not met?

Source Link
Cristian Lupascu
Cristian Lupascu
  • 1.4k
  • 1
  • 9
  • 18

I find that Roy Osherove's test naming convention is easy to apply and provides suggestive names for the test methods.

Roy proposes that the test method names should be composed of three parts:

  • MethodName (or PropertyName, as in our case)
  • StateUnderTest (a brief description of the scenario being tested)
  • ExpectedBehavior

Following this convention, the methods in the DoorTest class could be named:

  • IsVirtual_NameStartsWithLetterOtherThanV_ReturnsFalse
  • IsVirtual_NameStartsWithLetterV_ReturnsTrue

Following a convention like this can provides consistency and makes it easy to use and maintain the test code.

Also, having the three elements delimited by underscores provides good readability. In case a test fails, with only a glance, you are easily able to grasp all relevant information about the failure: what component failed? what was the failure scenario? what is the expectancy that was not met?