[Haskell-beginners] edit-compile-test loop

[Joe Fredette]

Well, basically I switch from doing manual "testing" (entering  
functions with test arguments by hand into ghci, checking types w/ the  
inferrer, etc.) to compiling via cabal build (which requires me to  
make sure I've got all the appropriate modules listed in the  
appropriate places, make sure I'm not importing hidden modules, etc)  
and running a test suite (typically QuickCheck properties with some  
HUnit thrown in around the IO stuff and for corner cases of functions  
(eg, making sure things fail gracefully when I have to write a partial  
function, etc)) and working generally more as if I were writing in a  
language like Java (where most of my dev cycle is interacting with  
JUnit, rather than a interpreter). Typically it works out to:

1> edit some stuff
2> cabal build
3> fix any errors; goto 1 else continue
4> run test suite [see 1]
5> if any tests fail, and that wasn't expected, fix the issue; goto 1  
else continue
6> goto 1 until ready for release.

Towards the release date, this process helps me add functionality  
slower, and ensure everything is actually doing what it's supposed to.  
I tend to work on projects solo, so I'll do various naughty things  
like develop without writing alot of tests or documenting, etc. When I  
get ready to release, I really want to make sure I've covered  
everything that needs to be tested with tests, documented everything  
appropriately. As I code (even before this part of the project) I  
generally keep track of what I should write tests for, even if I  
haven't written the test yet. During this phase I build up the test  
suite to cover all the things I've written down, and the test suite  
kind of becomes part of the specification at that point. If something  
in the future causes an early test to fail, then that change "breaks"  
the program, if it causes a current test to fail, then I might want to  
see if that test is really ensuring the property I want.

I should note, I'm not a CS-guy, I'm a math guy, and this kind of  
methodology is more like when I write a math paper than what I think  
most people do when they code. When I have a ECT loop for math papers,  
it starts with me making wild conjectures and "testing" them (trying  
to come up with proof sketches), later that turns to this slower  
process of actually, formally proving things (the compiling part of  
this cycle) and finally it hits the, "Now make it pretty" phase, where  
I eliminate superfluous arguments/lemmas, rework proofs to flow  
better, etc (the "make sure the tests pass" phase). I don't know if  
this is similar to "normal" dev cycles, but it does me nicely. :)

HTH

/Joe


[1] right now I use my own little hacked up testrunning script (just  
loads the stuff in ghci, and I have one function that sits in a base  
"test" directory, underwhich the project module hierarchy is mirrored.  
So if I have, as I do now, Text/HWN/Parser/HWN.hs, then I also have  
Test/Text/HWN/Parser/HWN_Test.hs. in the Test directory I have  
Test_Harness.hs, which has a main function which runs all the tests in  
the directories below it. Each directory has a similar Test_Harness.hs  
(though all the names are different) which loads all the tests of the  
directories below it, and exports a single test group. All of this is  
manual, though I've been planning a kind of manager thing for it  
lately. But thats a story for another day.

On Sep 21, 2009, at 6:22 PM, Tom Doris wrote:

> Thanks, this is very helpful; can you give more detail about your  
> process once you've transitioned to a "proper test harness/cabal  
> build", how does this usually hang together?
>
>
> 2009/9/21 Joe Fredette <jfredett at gmail.com>
> Assuming I'm starting a brand-new project, it starts by creating a  
> file in my code directory. initing darcs there, creating the .cabal  
> file, and creating a basic module hierarchy. After that, I `touch` a  
> couple of files. add the standard license/description/other header  
> info...
>
> When I'm working on the code proper, I have a screen session split  
> to a ghci session and a vim session editing the file. The ghci sits  
> in the base directory of the projects (where the _darcs folder is)  
> and has the files I'm working on loaded. I edit, ^a-tab to ghci,  
> reload, flip back, fix errors, repeat till it loads. After that, I  
> run a few tests to make sure the program does what I think it does,  
> if not, I fix it, then back to adding new functionality.
>
> I hope this is what you wanted to know. Towards the point where I'm  
> going to release a version, I  substitute the ghci-business to a  
> proper test harness/cabal build to make sure it compiles all  
> correctly.
>
> /Joe
>
>
> On Sep 21, 2009, at 5:35 PM, Tom Doris wrote:
>
> Hi
> I'd like to know what the typical edit-compile-test loop looks like  
> with the Haskell platform; that is, in C++ this would be edit, run  
> make to compile everything in the project into  libraries and  
> executables, then run an executable test suite. I'm confused as to  
> how people work on larger projects in Haskell - do you work on a  
> single module and load it into ghci to test as you develop, then  
> compile the entire package and run a test suite? Or do you generally  
> only use ghci for prototyping and not when in the middle of proper  
> development? Or do you compile the package and load that into ghci?  
> I'd like to know as I'm starting to work on patches for some hackage  
> packages which have proper cabal builds etc., and want to follow the  
> correct (and efficient!) convention.
> Thanks
> Tom
>
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
>