Parametrization being a bit too broad

[Martin Pool]

On 18 May 2011 11:39, John Arbash Meinel <john at arbash-meinel.com> wrote:
> 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

I think that's a great answer when you're sure it's one particular
function that you want to test.  We could add some parameterization
helpers for it.  It may not be enough in some of these important cases
though, because while the entry point method may be the same, it's
other down-call methods on the class that account for the difference,
or state created during initialization.  You also have to be sure that
there won't be changes later that cause it to become like this.

>
> 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

+1

Just generally I think our bug-oriented and review-oriented workflow
somewhat tends to squeeze out work towards just refactoring.  Jelmer's
cleanups recently have been good like that.  This kind of refactoring
of tests would be welcome.

Martin