[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 5.1 updates wanted, and CD remastered size w/ hardlink script

Hi Klaus,

Sorry for the late response. Holidays are over and my spare time is back to 
normal level, i.e. very close to zero.

> > Would it be possible before cloop image creation to identify
> > files/blocks/ranges that are unchanged compared to the previous image? If
> > so could these ranges be mapped to the same blocks during compression?
> No, and no. ...<snip>...

Too bad and too bad! ;)

> I disagree. This case is also an excellent academic example where an
> automatic unit test would most likely NOT have found a bug,

I am sorry, but I must disagree again. Testing is not about automatically 
finding new bugs (which is impossible anyway). It's about ensuring that a 
defined set of features works and known bugs never appear again. This is what 
we call the test coverage.

In this special case the testing procedure must click on the switcher and then 
check if kicker is still running. Before you apply your fix the test must 
fail. After the fix it must pass.

> I'm also teaching this stuff, occasinally.

I'm actually DOING this stuff, regularly.

> I agree that here should be a "checklist" for betatesters, but then,
> imagine how long testing the DVD version will take, before we can do a
> small bugfix update (and check again).

But this is exactly the reason to automate the testing!

> I am, as soon as you send me that automatic testing engine that finds all
> bugs in the DVD version before the release. ;-)

I would love to have that engine too for all my own software projects. 
Unfortunately you have to write the tests yourself.

> Also a problem: In order to run unit tests, you have to (in most cases)
> modify the software you want to test.

I have to disagree again. This is only necessary in (the very seldomly run) 
white-box tests. You are probably talking about something like QtTestLib 
(http://doc.trolltech.com/solutions/4/qttestlib/). Most of the tests in 
reality can be run as black-box tests. There are many very good engines 
available. You just have to use them! Here are some examples:

A good overview about testing tools (not just GUI ones) is available here:

> So, automatic testing DOES have its downsites.

The only downside I can see is that it needs some effort and dedication. But 
the advantage of ensuring software quality with a single mouse click during 
development time clearly outweighs this investment.

> This can be proven by really large sofware projects of really large software 
> companies, that STILL show bugs in spite of EVERYTHING having been run 
> through extensive unit testing for each release.

You are right. Automatic tests do not replace manual tests. It is also 
impossible to get 100% test coverage of non-trivial programs. Not with 
automatic nor with manual tests.

Thank you for listening to my rumblings, I really just want to be helpful 


Reply to: