Re: Rearchitecting froggy-test to a test-suite

[Chris Moller]

Sure, froggy's all over the floor right now. Since it's primary objective is sandboxing/tinkering/exploring what's possible, I expect a lot of it will be coding/use examples. As time goes on--and not much of that--I'll be reorganising the code, separating the components and writing docs. I'm also thinking of adding a separate interface library so people won't have to deal with all those ioctl() _IOW things and other messy/tricky bits.

It might take a week or so to put the framework for all that together.

Chris

Phil Muldoon wrote:

Hi Chris



Thoughts?

Phil

While we are in the earliest days of development, I'd like to propose a small change to the purpose of froggy-test. I've spent the last day or so going over the code. While what is there is great, I have difficulty in separating out what works, what doesn't, what is planned to be implemented, and what is planned to be removed. This is not criticism, this is somewhat normal in the early days of a project. However the principles of Test driven development can help us here. What would be really neat would be a set of concrete examples that could then form part of a froggy testsuite. So we'd have a quiesce only example; that in turn would form part of the quiesce test-suite. It allows newbie developers like me to quickly ascertain code snippets in a isolated, concrete fashion. It would also be neat to track regressions across development phases, even this early on.

--
Chris Moller

 I know that you believe you understand what you think I said, but
 I'm not sure you realize that what you heard is not what I meant.
     -- Robert McCloskey

signature.asc
Description: OpenPGP digital signature