[TIP] Testify

[C. Titus Brown]

Olemis wrote:
> Titus wrote:
> > So we have a bunch of nearly identical test frameworks, all with
> > slight syntactic differences, all serving nearly the same purpose within
> > slightly different constraints, with various levels of internal mungery.
> > People keep on telling me that their framework or approach is better,
> > or somehow rawks, but since they mostly decline to document this
> > simply enough for me to understand, or seem to regard arbitrary design
> > decisions and limitations as an "improvement", I remain unconvinced.
> 
> ... if this means that there should be a minimalistic core from which
> all other libs frameworks should be implemented , I like that idea .
> But in practice, in my case, the fact is that I'm not very comfortable
> with the std , and I think there are a lot of things that need to be
> enhanced and even major changes be introduced in there (and
> historically, from my perspective, I notice a lot of barriers to do
> this ...). This means that the time I can dedicate to convince people
> about taking one approach is better invested in forking and writing my
> own lib . Eventually if someone likes it, will use it ; and if nobody
> else does, I would, so that's enough to make me happy anyway .

There's a big difference between trying out new features in a new package, and
reimplementing the same old features in a new package.  I think Michael's
unittest2 changes could eventually serve as a good (or great) foundation for
future test packages, eliminating a lot of boilerplate foo that nose and
py.test and probably testify duplicate.  And I don't think there's any good
way to legislate nifty new features -- the people on this list can't even
agree on what those features should be, much less python-dev :)

So there's plenty of room for reinventing the wheel, especially if you're
looking for a differently-shaped wheel.

But if you do create a new package that you're putting forward for other
people to use, I for one will be grumpy if you don't:

 1) delineate at least one deciding factor that made you implement something
    new.  "I don't like using other people's code" is not a good reason IMO.

 2) document it reasonably well.

For example, I would argue that figleaf implemented some pretty nice new things
into coverage, and helped spur coverage.py to become better; despite Ned's
presumably TiC e-mail to the contrary a few days ago, he used to agree with me
that the old coverage.py was an unmaintainable and unextendable mess.  The same
holds true for pony-build, and twill, and pinocchio, and all the other crap
that I've foisted off on TiP with varying success.

So there's a bit more context for my grumpiness. I didn't mean to aim
it all at Rhett, though, so apologies for that.

Cheers, all :)

--titus
-- 
C. Titus Brown, ctb at msu.edu