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 14:13:52 GMT
Good Point. I will take it for a spin one day when I have enough time to
experiment.

On Tue, Jun 14, 2016 at 7:39 PM, Kent SĂžlvsten <kent.soelvsten@gmail.com>
wrote:

> This looks a bit similar to collection metrics for code running in
> production.
>
> Maybe the same mechanism could serve multiple purposes?
>
> /Kent
>
> Den 14-06-2016 kl. 13:32 skrev Niclas Hedhman:
> > 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.
> >
> > Example;
> >
> > 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
> > SideEffectOf<SomeComposite>
> >     implements SomeComposite
> > {
> >     @Service
> >     private TestPointReporter reporter;
> >
> >     @Invocation
> >     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
> > system.
> >
> > 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.
> >
> > Cheers
> > Niclas
> >
> >
> > On Tue, Jun 14, 2016 at 7:05 PM, Sandro Martini <
> sandro.martini@gmail.com>
> > wrote:
> >
> >> 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

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