Sorry, I didn't express my idea clearly enough during the meeting.
When I say function-based, it is not equal to functional test. Unlike
functional test, it is still a kind of white-box test.
And compared to method-based unit test, which consider the method as a test
object, it treats the module as an unit,
it guarantees the module works as expected after new requirements come or any
refactor requires.
Sorry for my poor expression, and let me take 'functest env prepare' of cli
module in Functest for
example(where the discussion comes from).
Instead of testing cli_base.env() and cli_env.prepare() separately,
we can test them together by writing the following four test cases(naming is
not very good just for description purpose):
test_cli_env_first_time_prepare()
test_cli_env_re_prepare()
test_cli_env_not_prepare_again()
test_cli_env_invalid_prepare_answer()
In this way, all the code can be covered as method-based way do, and at the
same time when something
changed in cli_env.prepare() and if it doesn't break the functionality it
should provide, we don't need to
rewrite the unit test, and on the contrary, if it breaks, the unit test will
detect it and notify us with a failure,
and of course, if the functionality needs to change, we should rewrite the unit
test.
If unit test is written in the way of method-based, almost everytime the code
change will cause the rewriting
of the test code, and further more whether it breaks the original
functionality, we cannot tell.
BRs
Serena
E: [email protected]
Original Mail
Sender: YujunZhang
To: ＜[email protected]＞＜[email protected]＞
CC: Ashish KumarTECH-DISCUSS OPNFV
Date: 2017/01/04 08:48
Subject: Re: [test-wg] unit test strategy in test projects
Some of my ideas on unit test inline
On Wed, Jan 4, 2017 at 1:26 AM ＜[email protected]＞ wrote:
Hi First of all, all the best for 2017! we got an interesting discussion on
unit tests in Functest this morning and more specifically on how we should use
them. see
http://ircbot.wl.linuxfoundation.org/meetings/opnfv-functest/2017/opnfv-functest.2017-01-03-08.00.log.html
from 08:36:00 Did you already elaborate any strategy regarding your unit
tests? - coverage target 100%? 80% any figure? exit jenkins if not reached? I
think 80% is a reasonable starting point. And we could apply it in verification
job but skip voting to avoid blocking fast development.
We may enforce it for stable branch as a release criteria.
- function / method based
Yes, we enforce a companion unit test for every module in QTIP and covers the
public interface.
- use of mock objects
mock is especially useful in unit test to isolate modules under test from others
- unit versus unit/functionnal tests
unit test and functional test focus on different target. Unit test guarantee a
module works as expected, while functional test ensures related modules works
together correctly to fulfil a functional requirement.
What are your best practices?
The above are my two cents in unit testing :-)
_______________________________________________
opnfv-tech-discuss mailing list
[email protected]
https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
