search

TomasMikula / libretto

Declarative concurrency and stream processing library for Scala
Mozilla Public License 2.0
199 stars 7 forks source link

Complete test coverage of the DSL #88

Open MateuszKowalewski opened 1 year ago

MateuszKowalewski commented 1 year ago

It seems not the whole implementation of the DSL is currently under test, or used in the example projects.

This seems risky.

As the DSL isn't such large complete test coverage seems doable.

The concrete use examples don't need so much tests OTOH. They are kind of test on their own. But the DSL (and it's implementation) should be imho under automated tests completely.

TomasMikula commented 1 year ago

It seems not the whole implementation of the DSL is currently under test, or used in the example projects.

This seems risky.

As the DSL isn't such large complete test coverage seems doable.

Agreed.

The concrete use examples don't need so much tests OTOH. They are kind of test on their own. But the DSL (and it's implementation) should be imho under automated tests completely.

Isn't that like saying that your Akka app doesn't need tests because it is already kind of a test (of Akka) on its own 😄

Don't necessarily look at tests of the examples as tests of Libretto. They are just tests of the examples 😉

MateuszKowalewski commented 1 year ago

Isn't that like saying that your Akka app doesn't need tests because it is already kind of a test (of Akka) on its own :smile:

Don't necessarily look at tests of the examples as tests of Libretto. They are just tests of the examples :wink:

Sure!

That part was more about priorities.

I think the examples have very high value. That's more or less a kind of starting point when you want to build something yourself.

But that code doesn't need much testing. Example input needs to output expected output. That's all.

I didn't look in detail what the test do actually. It was really mostly about the prios. Having tests for examples but not for the core of the whole system seemed a little bit off regarding prios.

Of course it's not bad to have properly tested examples! But for end-user code the framework should be mostly safe to use. It shouldn't be possible (in obvious ways) to construct bad or nonsensical programs anyway. That's the whole point of really type-safe APIs and "making illegal states unrepresentable". The type-checker does "the testing" for you! At least that should be the goal, imho.