Closed jrbeaumont closed 7 years ago
Oh I see. I can't believe I missed it before. I noticed it now, while doing some over the top testing of the concepts layout (now implemented)
@jrbeaumont Is it possible to add some tests, to make sure future commits do not break the conversion algorithm (testing that it correctly handles input, internal and output signals, as well as OR-causality)?
I'm sure it is, but we would need to test against an expected .g
file, which may be large. Do you know of a smoother way to do it?
I think if you split the test into multiple smaller independent pieces, it will work well:
.g
contents for a simple example with 1 input, 1 internal and 1 output signal, and no causality (i.e. compare the resulting String
, without actually writing a file).String
representation).Ok, that sounds reasonable. I will make a start and think on some more simple tests. Possibly something where we use 2 different concept descriptions to produce the same output, as with a cElement.
@jrbeaumont Ah, good idea! Such a test could look like:
testCElement = c1 == c2
where
c1 == cElement a b c
c2 == buffer a c <> buffer b c
You may need to implement an Eq
instance for STG concepts, that would sort the list of arcs before doing the comparison.
Thanks! That's what I hit during my demo in Tokyo :)