[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: koffice/kspread/tests
From:       Thomas Zander <TZander () factotummedia ! nl>
Date:       2004-09-14 17:11:52
Message-ID: 20040914171152.GA5478 () factotummedia ! nl
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tue, Sep 14, 2004 at 06:55:18PM +0200, Ariya Hidayat wrote:
> 
> >ALL the information for the test should be hardcoded in the test, in order
> >to let it be as small of a unit (to test) as possible.
> >This also makes coding the actual test a LOT simpler (as no code has to
> >be written validating the input) which allows you to write many little
> >tests.
> 
> So I can't have a test which works with the current document? I find 
> that will be handy, e.g. check whether cell storage (i.e. currently in 
> cluster system) is proper or not. Or is this not the way a test 
> framework should do?

In my experience thats not a good way to do things; no.

If you want to test if cell storage works you
a) instanciate a Cell 
b) fill it with some data
c) call store
d) check the backing store if the data went through.

Very low level and small tests (20 lines of code per test is usual).
What you want to do is do the 'fill with some data' a number of times with
different sets of data, chosen in a way that you test the limits of certain
parts.

The huge advantage of testing comes only when you make it possible to run
tests without a GUI (so you can run _all_ tests, with all data-sets, every
time you made a bugfix).
This leads to the behavior that if you wrote a number of tests for your
new class, and some wierd sideeffect someone else creates breaks your code
then currently its almost impossible for that other person to even detect
it broke.
Now its easy; just run the tests and see one break.

There are people who even go as far as to have a minimum of one test per
API call..
Thats probably overkill; but it illustrates the idea.

So; you should write a test and include the test-data with that test, which
means you don't want to run it on the current document.
If another document breaks the code (but not your test) you find out what
data it is and create another test (with that data).

I hope you can use this; its the general way testing is implemented.
-- 
Thomas Zander

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


[prev in list] [next in list] [prev in thread] [next in thread]