[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: Pete Batard
Subject: Re: [Libcdio-devel] [PATCH] UDF+ISO image extraction sample (and a plan for upcoming changes)
Date: Mon, 23 Jan 2012 14:23:29 +0000
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1

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.



reply via email to

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