polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sandro Martini <sandro.mart...@gmail.com>
Subject Re: Test Points
Date Tue, 14 Jun 2016 11:05:38 GMT
Hi all,
just for info I see some libraries like the great
[Akka](http://akka.io) that has an instrumented version too, so
if/when needed it's possible to use that version to gather more info
at runtime (via JMX, etc) have more asserts, and if needed even to set
some action ...
Maybe something like this could be applied here, with a variant in
published artifacts, but for sure it's not trivial to setup and keep
aligned with "normal" (not instrumented) version ...

What do you think ?

Bye,
Sandro

2016-06-14 2:26 GMT+02:00 Niclas Hedhman <niclas@hedhman.org>:
> Hi,
> I just had a revelation, watching Uncle Bob about TDD, combined with my
> knowledge about electronics design which uses Test Points (both at board
> level as well as silicon level)
>
> Since Zest "owns" the call chain, we could rather easily design a feature
> that is the equivalent to Test Points in electronics. Places where values
> are checked against an expectations.
>
> Isn't that what "assert" keyword is all about?
>
> Yes and no.
>
> Assert keyword can only tell if the value is within an expected range. It
> is rather difficult to communicate to assert what values are expected right
> now.
>
> What is the purpose of this?
>
> Well, I think that unit tests are a little bit "weak" since it is difficult
> to test that sequencing is correct, that interdependent computations are
> accurate and many other "functional" and "acceptance" test level issues. I
> think we can solve this rather neatly, by assembling the "real" application
> with additional Test Points (well the annotations are there all the time),
> Memory Es and feed actually data through and validate the results.
>
> So how is this going to work?
>
> Well, I don't know yet. But I imagine that One test consists of S setup
> steps, N steps of execution, and M results from T test points. Details not
> clear yet.
>
> I imagine that the Test Point is a combo of a SideEffect, an annotation and
> Reporting service. I imagine that the side effect has some way to know what
> is expected to happen at each test point.
>
> This is GutFeeling(tm) innovation at the moment, but I think there is
> strong values in here.
>
> As usual, feedback is most welcome...
>
> Cheers
> Niclas

Mime
View raw message