I don't know what these frameworks imply on the installation process. I would like to be able to compile 'containers' with every Haskell 98 compiler. If the test frameworks are itself basic Haskell and the tests are, too, this would be even better.

I think my proposal does not change basic aspect: - containers itself can be compiled with Haskell 98 compiler - tests already use test-framework which is not a part of Haskell 98 compiler If you want to compile tests with Haskell 98 compiler, it's another topic. Please propose it in another thread. --Kazu

Consistent unit tests and documentation seems like a nice benefit to me (don't forget about modifying and deleting unit tests). However, I agree that the structure imposed by doctest might lead to less than tasteful documentation.

I agree. I should implement document test which evaluates examples of Data.Map (for instance) directly: ---- insert 5 'x' (fromList [(5,'a'), (3,'b')]) == fromList [(3, 'b'), (5, 'x')] insert 7 'x' (fromList [(5,'a'), (3,'b')]) == fromList [(3, 'b'), (5, 'a'), (7, 'x')] insert 5 'x' empty == singleton 5 'x' ---- And sees if they return True. --Kazu

On 12/22/11 9:35 PM, John Alfred Nathanael Chee wrote:

On Wed, Dec 21, 2011 at 15:20, Joachim Breitner wrote:

...

I’m not sure what the benefit is here. containers is a “high profile” library which sees lots of effort. Introducing a new testing library (doctest) just to avoid having to add those test cases to the test suite does not seem to gain much, but takes away some flexibility while writing good documentation. Maybe the “==” form is more readable to some users?

Consistent unit tests and documentation seems like a nice benefit to me (don't forget about modifying and deleting unit tests). However, I agree that the structure imposed by doctest might lead to less than tasteful documentation.

I definitely prefer the "==" form for stating laws the interface follows. Doctest came from the Python tradition, which is a very imperative outlook on life. I wonder whether doctest could be modified to better match the programming, documentation, and testing style of Haskell. In particular, I'd expect it to recognize "=="-style statements as things to test. The only real issue is whether those statements should be considered unit tests or properties (testable by QuickCheck and SmallCheck), since those two categories have very different methods of being verified. -- Live well, ~wren

Doctest came from the Python tradition, which is a very imperative outlook on life. I wonder whether doctest could be modified to better match the programming, documentation, and testing style of Haskell. In particular, I'd expect it to recognize "=="-style statements as things to test. The only real issue is whether those statements should be considered unit tests or properties (testable by QuickCheck and SmallCheck), since those two categories have very different methods of being verified.

Isn't a unit test just a property with 0 free variable? If so, equality statements can always be handled by Quick/SmallCheck. Cheers, JP.