[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gzz] Re: Tests (was: Re: [Gzz-commits] gzz/gzz/view LinebrokenCellConte
[Gzz] Re: Tests (was: Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java)
Sat, 11 Jan 2003 13:07:03 +0100
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9
Tuomas Lukka wrote:
On Fri, Jan 10, 2003 at 09:01:34PM +0100, Benja Fallenstein wrote:
Well, fact: Nobody has taken the time to design the view framework so
that it can be tested sanely. If you're so serious about this, someone
should delete the whole gzz.view hierarchy right now and we should
re-write it, test first. (It is allowed to delete anything that won't
break tests, by your reasoning, so you wouldn't even have to write a PEG.)
In the extreme case, yes. Of course, deletion of a class for no reason
wouldn't be looked at nicely; there needs to be *some* reason for the action.
What I want to make sure is that people don't start being afraid
of changing things: did you read mudyc's change to gfx/demo/gldemo.py?
That is a symptom of something bad starting to happen when people
are afraid of changing things: everything starts getting more
complicated because no-one dares to change or delete anything
and just adds another variation.
Ok, I agree with this put-into-perspective statement :)
Why is the view hierarchy not testable in its current form?
Hm, I think I can explain easier by giving some examples of what we need:
- Mock fonts (could be a mock TextStyle class maybe) for which we know
the return values in advance, so that we don't depend on the fonts
and particularities of one specific computer/GraphicsAPI.
- A way to test vob hierarchies easily. It should be possible to give
the expected vob hierarchy declaratively.
- A way to test, 'which vob will be shown at window coordinates (x,y)?'
This should allow testing of the *results* of vob hierarchies
without actually looking into the hierarchies themselves.
That's what I can think of at the moment, but there may be more...
anyways, with tools like these, testing should become substantially easier.
Fortunately, we do already have a structure that doesn't paint directly
on the screen, so if the vobs work (needs to be separately tested), we
only need to test that the right vob structure is created (making our
task much easier).
How should it be rewritten?
I don't know. Thinking more about it, additional functionality like the
above may even suffice...
It may be more sensible to actually make a plan how we can get the
currently untested parts of the code in tested form.
That would be really good. Should we just take a list of classes and assign
them to people in TODO?
I guess that could work... hmmm... I think I'd prefer a "plan gzz.view
testing" item after the ht'03 deadline :-)