harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Avtamonov" <anton.avtamo...@gmail.com>
Subject Re: Unit testing revisited
Date Mon, 27 Mar 2006 08:14:03 GMT
On 3/27/06, Geir Magnusson Jr <geir@pobox.com> wrote:
[SNIP]
>
> I don't think it's easier to write test cases for internals though a
> public API, because you can call the internal methods directly to see if
> they do as they promise, where it's not so easy to always have the same
> thing happen through an indirect public API.
>
> Also, wrt things breaking..... yes, tests that ensure that something
> works as expected will need to change if the expectation changes.
>
> That also is exactly what you want, right?  To know if you broke a
> 'internal contract' in a class?

Hmmm... Lemme support Richard's point.
At the first, internals not just specify 'internal functional
contracts', but design decisions. Making redesign you will probably
have some (design-dependent) unit tests failing, despite functionality
is not changed. If so we will have to change the tests, right? If we
changing the tests we cannot be sure they still tests the original
behavior. IMHO, tests are the formal and executable way to represent
requirements (XP approach) so they should reflect the 'requirements
level'. In our case that is public API.

At the second, what we really need to satisfy is API behavior only.
Internal implementation is not significantly important if public part
works fine. I fond of XP and test-driven development and don't feel
that we need to test something which is not part of requirements :-).
If something is not accessible from the usage scenarios of public API
level, it is not important how it works (I believe this idea appeared
several times already in this thread).
I completely understand the issue of complexity if we test big amout
of code referenced by public API, however I believe that in the
majority of cases the behavior of each API method is not very
complicated and can be tested by few scenarios. At least I haven't
seen spec for some method of several pages long :-) Usually the
behavior is comparative simple.

At the end (but not least important) you have to 'verify' your tests
somehow. You prepare them basing on specification, however you should
check them on RI. Just to make sure test is correct, spec corresponds
to RI, etc. I cannot understand how it could be done for
'internals'...
I even know the objections, that only 'public API tests' (in .tests.)
should be run on RI. And I even probably agree...
Sometimes, it is really desire to write an 'internal' test. For
instance, if you use some sorting algoritms, or algoritms which find
next match, etc. In this case such 'utility' stuff might be tested
independently from the points of usage. However I believe that is not
'general case'.

--
Anton Avtamonov,
Intel Middleware Products Division

Mime
View raw message