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

[Pete Batard]

On 2012.01.23 12:35, Rocky Bernstein wrote:
> 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.

Yes. I've done ISO 9000 development in my time as well, where unit test 
and development go hand in hand, and you're not supposed to code a 
feature without first having a functional test for it (or at least the 
specs for a functional test, which you then have to implement). I also 
saw the time such a process can incur first hand...

> In this mode, one writes the tests before the code.

Well, as you can guess, my problem here is time.

This will just be too time consuming as far as I'm concerned, and I'm 
already going beyond my original plan, by delaying further development 
of my app as well as the other projects I'm involved with, to help 
libcdio. Helping libcdio is not something that was on my radar at all 
when I decided to add iso image support to my app (because I thought I'd 
just reuse 7-zip, which doesn't exhibit any of these issues). Thus, my 
original plan was to spend about one week or so on the whole feature, 
before moving onto something else... Famous last words.
Therefore, I'm already way over my allocated time budget here and 
effectively trying to reduce this unforeseen cost. But I still very much 
want to help libcdio as much as I can!

Now, if I had an employer paying for the FOSS development I do, I'd like 
nothing more than help out and spend time writing unit tests for 
libcdio, because I agree it'd be for the best. But I don't, so my time 
is limited. I already haven't gotten a chance to write unit tests with 
the other projects I'm involved with (for instance we could really use a 
multithreading sample in libusb), so I don't really see how I can 
suddenly justify doing so for libcdio.

Also, if we didn't have anything public to help reproduce the issues, I 
would agree that it'd be troublesome. However we do: the Windows image I 
pointed out does exhibit all the symptoms we want to fix. Therefore, 
creating unit test is mostly duplication of something we already have, 
and sounds like a very avoidable constraint.

> 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.

I have to disagree that the impact is minimal. I don't know anything 
about creating UDF images and barely a thing about the UDF file system. 
Doing things properly would require an extra time investment that I 
cannot really justify.

> 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.

My worry is that, if we actually wanted to do things properly for UDF, 
we shouldn't limit ourselves to just the Windows image issue 
replication. We'd need to add an Unicode test, a 4096(?) strategy test 
as well as review the various FIXME's in the code and so on. This is the 
only way I see to "allow people to have some confidence".
Ergo, since I do not see myself committing the time required for such 
additional tasks, and I don't think you will either, we may have no 
choice but take shortcuts here and there.

> 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.

Agreed. One should be able. One who is willing to commit time to write 
such a test. I don't see myself being such a person anytime soon, sorry.

I hope this doesn't sound to harsh, but that's the reality of my 
commitment to libcdio. Sometimes FOSS developers just have too much on 
their hands and need to take shortcuts and prioritize tasks. But because 
it's FOSS, I don't see that as an entirely unreasonable thing to do.

So I will finish by saying that, when developing for FOSS, and as 
opposed to proprietary, you're not supposed to be in the woods, at 
night, all alone with your code. Instead, you're be in broad daylight 
(open) and should be able to rely on others ("with enough eyeballs, 
etc."). Therefore, the methodologies that are aimed at proprietary 
development, even if they are also most certainly helpful when applied 
to FOSS as is, should allow some tweaking here and there, such as a bit 
of leeway for unit tests, if the end result is that more people will 
contribute.

Regards,

/Pete