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 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@haskell.org http://www.haskell.org/mailman/listinfo/beginners

Am Donnerstag 24 September 2009 00:03:03 schrieb Michael Mossey:

Trying to understand Douglas Auclair's article "MonadPlus - What a super monad!" here http://www.haskell.org/sitewiki/images/6/6a/TMR-Issue11.pdf

Defines

splits :: Eq a => [a] -> [(a,[a])] splits list = do x <- list return (x, delete x list)

choose :: Eq a => StateT [a] [] a choose = StateT (\s -> splits s)

I'm trying to understand what "StateT [a] [] a" means:

StateT stateType innerMonad resultType The state is a list of a, the inner monad is the list monad, apart from the newtype wrapper, it's [a] -> [(a,[a])]

I wrote

t1 :: StateT [Int] [] [Int] t1 = do s <- get return s

That compiles. Then I tried to write

t2 :: StateT [Int] [] [Int] t2 = do x <- [1,2,3] s <- get return (x:s)

I thought this would be fine because [1,2,3] is an example of a list monad.

Within one do-block, you can use only one monad. do x <- action1 y <- action2 return (f x y) desugars into action1 >>= (\x -> (action2 >>= (\y -> (return (f x y))))) (I used more parentheses than necessary to make the associativity clear, with less clutter, it's action1 >>= \x -> action2 >>= \y -> return (f x y) .) The type of (>>=) is (>>=) :: Monad m => m a -> (a -> m b) -> m b so you can use only one monad in such an expression. With StateT (most monad transformers, I think), you can achieve what you want with t2 :: StateT [Int] [] [Int] t2 = do   x <- lift [1,2,3]   s <- get   return (x:s) 'lift' lifts actions in the inner monad to StateT actions.

But I get

"Can't match expected type StateT [Int] [] t against inferred type [a]"

On Mon, Oct 19, 2009 at 12:25 PM, Roel van Dijk wrote:

...

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

I found the test-framework package to be quite useful for this.

http://batterseapower.github.com/test-framework/

Using the defaultMain function you can easily define a small program which will run all your tests (quickcheck, hunit or other). The only problem I had with test-framework is that it prints the test results in nice colours. It looks pretty in a console but unreadable in ghci.

Hackage seems to be down at the moment, but you can check out which other packages use test-framework on my hackage plaything:

http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/test-fr...

Yes, I've found this useful as well. I'm surprised it's not possible to turn off the colourisation... but `my-test --help` doesn't seem to offer any option for it. Maybe that's a good thing to add? ;-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe