On 07/19/2012 09:27 AM, damodar kulkarni wrote:

Good because library dependencies are reduced, but bad because tests are somewhat "disconnected" from the functions they are testing.

AFAIK, it's a good engineering practice to separate the tests from the code they are supposed to test. Code management issues will be there, but those can be taken care with the help of cabal like tool. That way, a person who wants to test will use the test-files and the one who doesn't want will be spared the trouble of separating tests from the intended function code.

This is the solution I'd prefer, but I quickly ran into a problem: if I want to test internal (non-exported) functions, the tests need to be in the same module as the code. Is there a way around this? (For now, I just put the code in the same file and depend on the test libs.)

On Sat, Jul 21, 2012 at 08:04:35PM +0200, Magnus Therning wrote:

On Sat, Jul 21, 2012 at 7:50 PM, Michael Orlitzky wrote:

...

On 07/19/2012 09:27 AM, damodar kulkarni wrote:

...

Good because library dependencies are reduced, but bad because tests are somewhat "disconnected" from the functions they are testing.

AFAIK, it's a good engineering practice to separate the tests from the code they are supposed to test. Code management issues will be there, but those can be taken care with the help of cabal like tool. That way, a person who wants to test will use the test-files and the one who doesn't want will be spared the trouble of separating tests from the intended function code.

This is the solution I'd prefer, but I quickly ran into a problem: if I want to test internal (non-exported) functions, the tests need to be in the same module as the code.

Is there a way around this?

(For now, I just put the code in the same file and depend on the test libs.)

A common issue. I, and some others I've seen, have a FooInternal module exporting *everything* for the tests, and a Foo module exporting only the public API.

I do this too. (For an example, see http://hackage.haskell.org/package/split ). It has another benefit beyond testing: I tend to export both modules from the package, and make it clear that beginning users should start by looking at the module with the public API; but for power users who want more control or access and don't mind the possibility of shooting themselves in the foot, the "export everything" module is also available. -Brent

On Sat, Jul 21, 2012 at 02:53:41PM -0400, Michael Orlitzky wrote:

On 07/21/2012 02:04 PM, Magnus Therning wrote:

...

On Sat, Jul 21, 2012 at 7:50 PM, Michael Orlitzky wrote:

...

On 07/19/2012 09:27 AM, damodar kulkarni wrote:

...

Good because library dependencies are reduced, but bad because tests are somewhat "disconnected" from the functions they are testing.

AFAIK, it's a good engineering practice to separate the tests from the code they are supposed to test. Code management issues will be there, but those can be taken care with the help of cabal like tool. That way, a person who wants to test will use the test-files and the one who doesn't want will be spared the trouble of separating tests from the intended function code.

This is the solution I'd prefer, but I quickly ran into a problem: if I want to test internal (non-exported) functions, the tests need to be in the same module as the code.

Is there a way around this?

(For now, I just put the code in the same file and depend on the test libs.)

A common issue. I, and some others I've seen, have a FooInternal module exporting *everything* for the tests, and a Foo module exporting only the public API.

I think I could get rid of the test lib dependencies this way, but doesn't the export-everything approach prevent GHC from making certain optimizations?

GHC can be quite a bit more aggressive with pieces of code if it knows they are not exported.

(I think I may have had evidence of this at one point, but who knows now.)

[1] http://www.haskell.org/ghc/docs/latest/html/users_guide/faster.html

Very possible but correctness trumps speed ;-) The only only solution I've thought of is to use a C preprocessor to control what's exported. Of course that means the tests can't link against the library. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus@therning.org jabber: magnus@therning.org twitter: magthe http://therning.org/magnus I invented the term Object-Oriented, and I can tell you I did not have C++ in mind. -- Alan Kay