[MERGE] fix add in view-aware trees

John Arbash Meinel john at arbash-meinel.com
Wed Mar 18 22:18:15 GMT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Clatworthy wrote:
> Robert Collins wrote:
>> On Thu, 2009-03-19 at 06:18 +1000, Ian Clatworthy wrote:
>>> By design, most of the view handling is done
>>> in the UI level (builtins.py) so this test multiplication is required
>>> at that level and not just at the API level.
>> Is it possible to move the view handling out of the UI? bzr-gtk, qbzr
>> etc will all have to duplicate it as it stands. blackbox tests test the
>> entire stack so I'm rather uncomfortable with needing to multiply them,
>> and that makes me uncomfortable about the design making it necessary for
>> us to do that.
> 
> Not in the short term. I like the idea of the UI layer being a thin veneer
> over API calls but that simply isn't the case for most commands, and
> therefore testing 99% of the app just at API level isn't currently realistic.
> 
> The entry points for view handling are thin: builtins.tree_files() and
> builtins.tree_files_for_add(). Perhaps we need to move those out of
> builtins.py into their own module and have explicit tests for them.
> Even then, I don't think we should underestimate the value of
> end-to-end black-box testing.
> 
> Ian C.
> 
> 

The thing is, any test that needs to be permutated on various formats is
leakage of the Interface. Considering that we have 6 repo formats, 6
branch formats, 3+ working tree formats, and 5 transports, it is *very*
important to have proper abstractions or you end up with 6*6*3*5=540
permutations that need testing.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknBcycACgkQJdeBCYSNAAO4SgCfTU4Sn6SqXCZmPxMUw8ElnHxE
Vf0AoLTdyveACrkpLejhg0vvDWj+AtGE
=UtPz
-----END PGP SIGNATURE-----



More information about the bazaar mailing list