Re: How to use TDD to test a process?
"Muppalla Sree Surya Prakash [email protected] [testdrivendevelopment]" <[email protected]> Tue, 26 Apr 2016 04:42:28 +0000
| Newsgroups | gmane.comp.programming.test-driven-development |
|---|---|
| Message-ID | <CAP8jZj0ObdVr_PZ_r4g6Tia_ny6D1gBC7BPE1-BFrWVbty2T_w@mail.gmail.com> |
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 *<Method name under
test>__<Test conditions, separated by single underscore>__<Expected result>*
)
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
On Tue, Apr 26, 2016 at 10:11 AM [email protected]
[testdrivendevelopment] <[email protected]> wrote:
>
>
> Thanks for the reply.
> Yes, actually I don't want to know the side effect. I just want to test
> the logic. I had planned to use stub or mock. But there are several
> branches. I thought it is a little duplicated. Because if gotten good code
> coverage, in every case I have to write the stub or mock for methods
> called. Could you give me some advice? Thank you.
>
>