On 10/ 6/10 09:05 AM, Dermot McCluskey wrote:
Keith,
Responses below.
An updated webrev is at:
http://cr.opensolaris.org/~dermot/webrev_mp_mw_03/
[...]
test_mp_without_engine.py:
Missing: Tests that run _load_manifest() directly (if some of the
existing tests hit that logic specifically, they should be written
to call _load_manifest directly, rather than via parse()). Only a
few test cases are needed - specifically, maybe 1 success case with
xinclude, 1 with dtd_validation=True, 1 with
attribute_defaults=True; 1 error case where an IOError ->
ManifestError occurred, and 1 where XMLSyntaxError -> ManifestError
occurred.
_load_manifest is not a public API, it is only a convenience function.
So, if I can test the code without directly calling this function,
should
I not stick to testing the APIs?
For reasons similar to the above on execute()/parse(), it really is
better to have tests against _load_manifest() call the function
directly, rather than indirectly via other APIs, so that as the code
evolves in the future, the tests are maintainable (no one wants to
spend a lot of time maintaining test code) and accurate (if someone
fixes a bug by changing _load_manifest, we want to see the
_load_manifest tests break, not the parse/write/execute tests break).
I accept your point. Some of my tests are clearly more integration
tests than
proper unit tests. I will bear this in mind in future.
I've added a new test module, test_mp_load_manifest.py, that adds the
additional tests you
suggest and have removed a few of the tests from test_mp_with_engine
that were checking
similar functionality by via higher-level API calls.
I have not, however, done a complete reorg of the tests to fit in with
this scheme. I hope
that is sufficient for now?
Thanks,
- Dermot
LGTM. Like I said, a complete reorg isn't needed. Thanks!
- Keith
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
