Re: [Suggestion] GNUstep-test for quality control (WAS: Re: deferreddeallocation)

[Alexander Malmberg]

Yen-Ju Chen wrote:
> >From: "Alex Perez" <aperez@student.santarosadu>
> >To: <discuss-gnustep@gnu.org>
> >Subject: [Fwd: Re: deferred deallocation of local objects]
> >Date: Tue, 14 Oct 2003 13:52:08 -0700 (PDT)
>   [snip]
> > >
> > > Checking that code works BEFORE actually commiting it to CVS is the
> > > issue here.
> >Exactly. It's about quality control, or the lack thereof, and nothing
> >more.
> 
>   Since it is difficult for anyone to test GNUstep on multiple platforms,
>   I would like to suggest a GNUstep-test for testing.
>   I know there are some testing code in GNUstep,

Yes, a test framework (greg) using guile, and a test suite with
(currently) 2884 tests.

>   and some of them use guile which I will never try to use.

Why not? Running "make check" or "make verbose" in the test suite
directory isn't hard. Is the dependency on guile that bad?

Yen-Ju Chen wrote:
>   A well-written test suit can be used for each release
>   to make sure nothing is broken when some other bugs are fixed.

It could be used on each commit. Eg., gcc works this way: nothing that
isn't highly obvious is committed unless it has been tested and found to
cause no new failures.


Chris Hanson wrote:
> On Tuesday, October 14, 2003, at 06:48  PM, Chris B. Vetter wrote:
> > Besides that, a test scenario can only check so many features but not
> > every possible issue.
> That's not necessarily the case.  You can get very high test coverage 
> if you develop code test-first using a good unit testing framework, 
> Test Driven Development, and refactoring techniques.

Well, that depends on what you want to cover. Generally, I'd say that
test-first unit tests can achieve good coverage of features of the
"interface", while bug-based tests cover features of the
"implementation".

Anyway, the merits of test-first are fairly irrevelant in our case since
most of the code that needs testing has already been written. :)


Pete French wrote:
> > When implementing a feature, you first write a simple test case for one 
> > aspect of that feature.  Build, the test suite runs including your new 
> 
> Out of interest, how do you test the testing code ? Havent you just
> moved the problem to a different bit of code ?

In a sense, yes. You're only testing that the test suite and the
implementation are consistent with each other.

Testing is no silver bullet. Getting the tests right is very important,
so you still need to make sure that you understand the interface, and
you can't be sloppy just because you're doing test-driven development.

In practice it works well most of the time, though. By expressing the
intended behavior twice (the code and the tests), and in different ways,
you're less likely to make the same mistake in both places (for some
classes of mistakes; it won't help you with a fundamental
misunderstanding of what the code should do).


Well, that got a bit long so I guess I'll save my thoughts about
improving the GNUstep test suite for later.

- Alexander Malmberg