Parametrization being a bit too broad

[John Arbash Meinel]

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

On 5/18/2011 12:27 PM, Vincent Ladeuil wrote:
>>>>>> John Arbash Meinel writes:
> 
> <snip/>
> 
>     > Thoughts?
> 
> It's a very tough problem. If we try to get too smart about reducing the
> parametrization, we risk missing some side-effect.
> 
> So there is no obvious answer. There are certainly cases where tests
> should be written closer to the feature and just be relied upon by
> higher levels but finding them is kind of an art...

So one idea was for tests do define the actual function that they are
testing. (Such as Repository.apply_inventory_delta). And then the
parametrizer would create the full width of tests, but can keep track of
a set of functions it has tested. Like:

 if func in self._tested_funcs:
  self._tested_funcs.add(func)
  run_test()
 else:
  # this version of the test has already been run.
  pass

Though I think I like Martin's answer as well. Which is that Repository
et al are a bit too big. We should be breaking up as much functionality
into helper classes. Those classes can be more focused, and be run as
the scenario.

Then instead of having CHKInventoryRepository have a different
apply_inventory_delta function, you would instead have:

CHKInventotryRepository._delta_applier = CHKInventoryDeltaApplier

Note that you could still have a public api on Repository for
convenience. Just more split-out and focused classes. I believe the
general rule is something like "a cohesive class has all functions using
more than 50% of the attributes".

http://www.aivosto.com/project/help/pm-oo-cohesion.html

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

iEYEARECAAYFAk3TodAACgkQJdeBCYSNAAOaiACfShRXV7+sJoUMJv0NnJni5ohI
GxEAoLoQqPwBYpFrqukcEeiQkEKMAWCs
=xO9K
-----END PGP SIGNATURE-----