Tests 2

[mvdan]

Just a continuation of what I began yesterday. Also with a slight simplification to keep test bodies smaller.

@snowleopard a few questions:

• I want to do concepts that have three signals (e.g. A B C). I've seen that if I just define Signal as A | B | C, the two-signal concepts will not work properly. So I'm thinking that perhaps we should use X | Y for those that need two, and A | B | C for those that need three. This solution doesn't scale very well though, as we'll run out of intuitive chars very soon.
• Should I be testing initial states other than const False?
• Should I be asserting the states at each step, just like I'm asserting the enabled transitions? Or would that be redundant?
• Is there a less verbose way to do this than to keep creating new names for each state? initState, afterA, afterB... If we want to go further, naming the states will become somewhat complicated.

[snowleopard]

I decided to merge and then do quite a bit of refactoring. Should be complete today.

[snowleopard]

@mvdan Answering some of your questions:

• We can use A | B | C with two signals if we declare certain signals silent. More generally, we can probably switch to the following type: type Signal = Int during testing, so we don't have to bother with choosing names.
• We can try to rely on QuickCheck for automatically testing with different initial states.
• We could turn simulation into a monad and then we won't have to explicitly carry around the current state of a circuit under simulation.

[mvdan]

More generally, we can probably switch to the following type: type Signal = Int during testing, so we don't have to bother with choosing names.

SGTM

We can try to rely on QuickCheck for automatically testing with different initial states.

Can you make sure that the important bits are covered then, though? From what I can see quickcheck is like fuzzy testing. Which is good and can be part of CI, but manual specific tests should still be there.

We could turn simulation into a monad and then we won't have to explicitly carry around the current state of a circuit under simulation.

My haskell falls a bit short here, so I'll look closely at your code if you do this :)

[snowleopard]

From what I can see quickcheck is like fuzzy testing. Which is good and can be part of CI, but manual specific tests should still be there.

Yes, that's right. The standard pattern is: several custom tests, plus a bunch of general properties that are checked by QuickCheck and often become part of documentation.

[snowleopard]

@mvdan Have a look at how I reworked tests & associated concepts infrastructure.

• We can now use Simulation monad for building and composing interesting simulations without explicitly passing the state around. PureSimulation should be used when we don't need to run the simulation inside any other monad. In Test we do need to run the simulation inside the IO monad as we need to write a test log. Same for Main, but in general I hope we'll find PureSimulation useful.
• Regarding the A | B | C issue: simply use the silent concept to shut up unused signals.
• You might also like how I modified the initial state in the inverter test: initialState = State $ (== B).

[mvdan]

We can now use Simulation monad for building and composing interesting simulations without explicitly passing the state around. PureSimulation should be used when we don't need to run the simulation inside any other monad. In Test we do need to run the simulation inside the IO monad as we need to write a test log. Same for Main, but in general I hope we'll find PureSimulation useful.

Cool, thanks!

Regarding the A | B | C issue: simply use the silent concept to shut up unused signals.

OK.

You might also like how I modified the initial state in the inverter test: initialState = State $ (== B).

Damn, that's clever. Everything that came to my mind was way longer.

Also, isn't the $ redundant?

[snowleopard]

Also, isn't the $ redundant?

You are right! Fixed now :-)