polygene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niclas Hedhman <nic...@hedhman.org>
Subject Re: Test Points
Date Tue, 14 Jun 2016 11:32:56 GMT
Well, I bet that it is relatively difficult for Akka, at least in the Java
version. In Scala, they might have a compiler plugin to achieve this.

For Zest, the situation is quite different. In fact, I don't even think we
need any additional features in Zest Core to do this. Anyone can do it on
their own using the regular SDK.


public interface SomeComposite
    void doSomething( String arg1, ZonedDateTime time );

    ZonedDateTime findSomething( String arg );

    MyState myState();  // getter for some other state.

@AppliesTo( TestPoint.class )
public abstract class SomeCompositeTestpoint extends
    implements SomeComposite
    private TestPointReporter reporter;

    private Method method;

    public void doSomething( String arg1, ZonedDateTime time )
        reporter.report( method, null, arg1, time );

    public ZonedDateTime findSomething( String arg )
        ZonedDateTime result = next.findSomething( arg );
        reporter.report( method, result, arg );

That way, means that the TestPoint side-effect can be Generic and not
needed to be created for each type to test. But possibly, the above should
also do the assertions, otherwise the Reporter would need to have a
subsystem for that. In which case, it is a matter of, how are the
assertions being set up... Well, to obtain that from a service of some
kind. And then some API/SPI is needed for that... and so on. SO I am not
sure what is better.

Anyway, at bootstrap the SideEffect is added when we do tests in question
and otherwise not. So, the only "keep in sync" is @TestPoint will remain in
the code and that could be a good thing. It could be important API points
that we want to preserve, whereas other places we don't want TestPoints as
that code is free to change and we should probably not build a fragile test

My question is basically around different ways that this can be solved, and
whether there might be some super-nice way to do this "if only we had this
particular feature in Core". Otherwise, it can be made as a library.


On Tue, Jun 14, 2016 at 7:05 PM, Sandro Martini <sandro.martini@gmail.com>

> 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

Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

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