Property-based tests for encoder and decoder about tomland HOT 6 CLOSED

Hi! Very cool package.

I want to have a go at this, because a) I love toml and need it for my projects, and b) I want to learn how to write and structure tests with hedgehog. I'm not the most advanced Haskell programmer, so I'll probably report back with questions if you don't mind.

For now, could you explain a little bit the idea behind the directory & module structure?

test
├── Spec.hs
└── Test
    └── Toml
        ├── Gen.hs
        ├── Parsing
        │   ├── Property.hs
        │   └── Unit.hs
        ├── PrefixTree
        │   ├── Property.hs
        │   └── Unit.hs
        ├── Property.hs
        └── TOML
            └── Property.hs

So I understand Gen.hs, and I guess that the toplevel Test.Toml.Property would be the place to include point 3.?

Would point 2. mostly rely on the generators in Test.Toml.Gen?

With "converter", do you mean a TomlCodec MyType like in Playground.hs?

Beautiful and very readable code by the way. I extra appreciate all the qualified imports.

from tomland.

@2mol I appreciate that you want to work on the tomland!

so I'll probably report back with questions if you don't mind.

That's completely, okay, feel free to ask any questions!

I guess that the toplevel Test.Toml.Property would be the place to include point 3.?

Well, Test.TOML.Property might not be the best name for the module. This module contains Semigroup and Monoid laws check in general form and later it's used for two types: PrefixTree and TOML. So I can write these laws only once and then instantiate to specific type. This is more like Test.TOML.Monoid (and probably should be renamed to this).

I think that the best place for this issue test is the Test.Toml.Codec.Property module.

With "converter", do you mean a TomlCodec MyType like in Playground.hs?

That's true, I mean bidirectional converter of type TomlCodec.

The idea of this property test implementation is the following. At first I was thinking about creating fat data type that contains all possible fields of different types that are supported by tomland. But now I think that it's better to create polymorphic newtype and then write a bunch of different codecs for this type, like:

newtype CodecWrapper a = CodecWrapper a  -- probably with better name

boolTest :: TomlCodec (CodecWrapper Bool)
boolTest = CodecWrapper <$> Toml.bool

integerTest :: TomlCodec (CodecWrapper Integer)
integerTest = CodecWrapper <$> Toml.integer

So the idea is write bunch of such codecs for every combinator from Toml.Bi.Combinators module.

Beautiful and very readable code by the way. I extra appreciate all the qualified imports.

Thank you very much 😊 This import policy is a part of style guide and I'm strong advocate of such imports 😄 I think that imports are important to help to understand code (especially when tooling current is not that great). Helps to understand code better for people who are unfamiliar with it.

from tomland.

CodecWrapper doesn't really fmap into Toml.integer

Yes, you are right. I was to hasty. This is the correct code:

newtype CodecWrapper a = CodecWrapper { unWrap :: a } -- probably with better name

boolTest :: TomlCodec (CodecWrapper Bool)
boolTest = CodecWrapper <$> Toml.bool "foo" .= unWrap

Why the newtype? Aren't we basically just testing every individual Toml.integer, Toml.bool etc?

At the beginning of this issue I was thinking about testing one huge data type, so we call also test all instances for the Codec data type. But then I decided that testing each combinator independently is better idea, so here comes ides with newtype. You may notice that each combinator also takes Key argument and this Key is configured inside specific TomlCodec.

So now I think that maybe it's most likely a better idea to create single fat data type and test it as it was initially intended 🤔 Sorry, if I don't have ready-to-go solution for this problem immediately. I never wrote tests for bidirectional conversion library, so the design space is still too broad.

Let me know if you're on slack or IRC somewhere, I'd love to pester you with questions in real-time.

You can tell me email (or send it at [email protected]) and I can add to our organisation Slack where you can ask any questions about tomland library)! Private messages in Twitter work quite good as well 👍

but if I try to open it in a repl with cabal new-repl tomland:tomland-test

Hmm, that's really weird 🤔 The similar issue recently was on Travis CI for the tomland library but then it fixed itself. cabal new-update helped. If it doesn't help, I can try to look at the issue.

from tomland.

Okay, no need for big data type. I think that simple newtype for each converter is okay.

from tomland.

Ok, I'm making a bit of progress understanding the library.

Two things that are still a bit confusing to me:

1. Why the newtype? Aren't we basically just testing every individual Toml.integer, Toml.bool etc?
2. CodecWrapper doesn't really fmap into Toml.integer etc, since for example CodecWrapper <$> Toml.bool "bla" seems to give me a Codec ... instead of a BiCodec ...?

edit: I have to get more details about point 2, after I fix my broken stack :) But for now I can of course change the newtype a little and use it with

boolTest :: TomlCodec (CodecWrapper Bool)
boolTest = Toml.dimap unwrapper CodecWrapper $ Toml.bool "bla"

Let me know if you're on slack or IRC somewhere, I'd love to pester you with questions in real-time.

from tomland.

(moved from separate issue to here)

I'm getting the weirdest issue. Just adding a module Test.Toml.Codec.Property and importing Hedgehog will break something in the Spec.hs module.

Basically if I run cabal new-test or stack test, the whole test-suite runs fine, but if I try to open it in a repl with cabal new-repl tomland:tomland-test or the stack equivalent, then I get

test/Spec.hs:7:1: error:
    Could not find module ‘Test.Tasty.QuickCheck’

Then, if I add tasty-quickcheck ^>= 0.10 to tomland.cabal, then cabal new-test fails with the following:

test/Spec.hs:38:16: error:
    • No instance for (QC.Testable Hedgehog.Internal.Property.Property)
        arising from a use of ‘QC.testProperty’
      There are instances for similar types:
        instance [safe] QC.Testable QC.Property
          -- Defined in ‘QuickCheck-2.12.6.1:Test.QuickCheck.Property’
    • In the second argument of ‘($)’, namely
        ‘QC.testProperty "reverse" Test.Toml.Codec.Property.prop_reverse’
      In a stmt of a 'do' block:
        t2 <- pure
                $ QC.testProperty "reverse" Test.Toml.Codec.Property.prop_reverse
      In the expression:
        do t0 <- testGroup
                   "tomlRoundtrip" Test.Toml.Parsing.Property.test_tomlRoundtrip
           t1 <- HS.testSpec "Parser" Test.Toml.Parsing.Unit.spec_Parser
           t2 <- pure
                   $ QC.testProperty "reverse" Test.Toml.Codec.Property.prop_reverse
           t3 <- testGroup
                   "PrefixTreeInsertLookup"
                   Test.Toml.PrefixTree.Property.test_PrefixTreeInsertLookup
           ....

from tomland.