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

[Rocky Bernstein]

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

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


Anything can be overdone. Part of the art is the right level of testing or
comments.  It is not black or white as to whether something is tested or
commented. And as you suggest, different for projects and different
considerations the level changes.



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


And UDF support wasn't on mine. But as you write below, famous last words.
Many of the projects I've gotten involved with have gone in lots of
directions I never foresaw. But that's probably a good thing - the road
less travelled.


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


Ok. Since I think it important, unless there are other volunteers I'll look
into adding tests for the very specific bugs that are encountered.

There is nothing in TDD that says one has to support all of UDF. I'm taking
a more pragmatic approach here. The are specific bugs and deficiencies
you've encountered with libcdio are the ones we want to make sure are
addressed forever.

And as I wrote before, having even slightly better UDF support may be just
enough to lure more people to handle all those other more thorny issues.



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

I understand where you are coming from, but suggest even in those other
projects it may be a mistake. With testing there is a chicken-and-egg
bootstrap problem. Unless one is working in an environment like
Ruby-on-Rails where there already has been a lot of work done to support
testing (even to the extent of automatically cloning databases), there is
some initial hit one takes in setting up tests. But after doing that, the
testing becomes easier. And the pay-off in my view is worth the work done.

Here is something similar. You just wrote an example program. It was
probably easier to do because there were other example programs and the
build framework to cut and paste from. Experience has shown that the
example programs have been very helpful, although when I wrote the first
ones, it felt more as an afterthought.

So again, perhaps if a framework for testing UDF images is started adding
to that for bugs that you want to fix won't be too much trouble. And there
may be some code in the testing that you can use on the other projects.




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