polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Test Points
Date Tue, 14 Jun 2016 00:26:04 GMT
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

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...


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message