开云体育

Here is the a list of possible tests for the UserService.Record method:

?

?? Record__UserWithSameNameAlreadyExists__DeleteTheUser ???????????????????????????????????????????????? // Asserts only on calling the method _userDao.Delete with appropriate arguments – you have to use a mock to do this

?? Record__ UserWithSameNameAlreadyExists _DeleteFailed__ReturnsFalse ?????????????????????? // Asserts on the method Record returning false – you have to use a stub here to ensure that Delete returns false

?? Record__ UserWithSameNameAlreadyExists__SavesNewUserDetails?????????????????????????????????? // Asserts only on calling the method _userDao.Save with appropriate arguments (the passed user in this case) – again a mock is needed

?? Record__ UserWithSameNameAlreadyExists_SavingFailed__ReturnsFalse????????? ??????????????? // Asserts again that the method Record should return false – a stub for the method Save to return false

?

(The test names are written using the notation ____)

?

Pl. note that this is the minimum no. of tests that the method Record can have (given its cyclomatic complexity - 4)

There may be other cases, which evolve depending on the data complexity, which gives more dimensions to the above tests. For ex. there may be null data, which is probably expected/not expected to be handled by the method.

?

It is also but usual to be tempted to assert on more than one expected result in a single test, but the best practices prescribe not to do so, as it may be not be clear - which expectation failed.

?

One way to check if you have enough tests is to see, if the list of tests are giving you the functional specification of the method under test. It is more efficient and useful technique in a test first approach, where the unit test spec could be checked before coding. Also, it may be possible to sort out glitches like, whether the userDao is actually expected user name or id.

?

Best Regards,

Surya