[Top][All Lists]

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

Re: [Libcdio-devel] [PATCH] UDF+ISO image extraction sample (and a plan

From: Rocky Bernstein
Subject: Re: [Libcdio-devel] [PATCH] UDF+ISO image extraction sample (and a plan for upcoming changes)
Date: Mon, 23 Jan 2012 07:35:00 -0500

On Mon, Jan 23, 2012 at 5:35 AM, Pete Batard <address@hidden> wrote:

> Oh, and as I explained, unless we have a >4GB (or >2 GB if all indexes are
> signed) image with a >4GB (2GB - signed) file in it, tests for large files
> on 32 bit systems will of course not be representative.
> I'm afraid figuring out how to create such an image from scratch, when I
> know of one freely available, is not part of my current plan. I feel there
> is just too much that will keep us busy already, without having to worry
> about adding an extra step. I hope that's OK.

There is a style of programming development called "test-driven
development" (TDD) [1] and something similar called "behavior-driven
development" (BDD) [2].  Ruby on Rails programmers use it all the time, and
I have found this style of development helpful in code and projects I write.

In this mode, one writes the tests before the code. Sure, you use this real
image to find bugs because that's what you really want to be able to
handle. However after finding the bug one can isolate the bug down to a
specific small test case that exhibits the bug and *then* fix that after
the test is in place.

Yes, this can slightly slow down coding in the same way say as writing
function comments giving a behavioral specification can slow down coding.
Invariably it is a little extra work because things change as one
understands more so that means updating comments and tests.

However, if you look at this in the big picture as -- one has to do for
long-lived and large projects -- the tests are essential to ensure we don't
regress and to allow people to have some confidence that this code does
what it is supposed to do in their environment.

I am of the frame of mind that I write *some* tests and comments as I go
along rather than do *everything* after the fact. There may be a stage
where I tidy up code, comments and improve tests. And by doing so, I can
ensure no regression of the things I am focused on while I am developing
the code.

Specifically here, you found a problem where it looks like sequential
reading of files is buggy. This thing where a variable should be reset to 0
after use or before the next read. It strikes me that one should be able to
write a small UDF image to exhibit that behavior. It might just be as
simple as UDF with two or three files in it.


> Regards,
> /Pete

reply via email to

[Prev in Thread] Current Thread [Next in Thread]