Serena, Maybe the term `interface` fits better here. I agree with you that the target of unit test in Python is *module*.
We ensure with unit test the existing interfaces of the module are not broken by new code and new interfaces implemented work as expected. The private methods (which does not expose anything of the module) is not something promised by the module and we don't need to create dedicated unit test for them. They are normally covered by the unit test of related public methods. My another two cents... On Wed, Jan 4, 2017 at 2:04 PM <[email protected]> wrote: > 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 Kumar;TECH-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
