On Thu, Dec 3, 2009 at 11:51 AM, Robert Collins
<email address hidden> wrote:
...
> - similarly, some of our layers check invariants. how do we do that
> with testresources?
>
> Point me at some code, I'll have a think.
>
> - zope.testing at least used to ignore any special suite you specified
> for your tests, which would mean testresources' OptimizingTestSuite
> would be useless during a transition.
>
> It rearranges things as it pulls the layers out. I have in my head an
> adapter for testresources to honour layers-as-resources, which would
> permit nuking zope.testing's layer support on day one.
>
That'd be aces.
> - we need to define the resources launchpad tests need and come up with
> a transition strategy.
>
> I think an incremental approach might be easier to deploy.
>
Well, yes. That's what the comments are getting at. Could you please
expand on what you mean here?
On Thu, Dec 3, 2009 at 11:51 AM, Robert Collins
<email address hidden> wrote:
...
> - similarly, some of our layers check invariants. how do we do that
> with testresources?
>
> Point me at some code, I'll have a think.
>
lib/canonical/ testing/ layers. py
http:// bazaar. launchpad. net/~launchpad- pqm/launchpad/ db-devel/ annotate/ head:/lib/ canonical/ testing/ layers. py
> - zope.testing at least used to ignore any special suite you specified as-resources, which would
> for your tests, which would mean testresources' OptimizingTestSuite
> would be useless during a transition.
>
> It rearranges things as it pulls the layers out. I have in my head an
> adapter for testresources to honour layers-
> permit nuking zope.testing's layer support on day one.
>
That'd be aces.
> - we need to define the resources launchpad tests need and come up with
> a transition strategy.
>
> I think an incremental approach might be easier to deploy.
>
Well, yes. That's what the comments are getting at. Could you please
expand on what you mean here?
jml