Junit Rules

[Niclas Hedhman <ni...@hedhman.org>]

Hi,

I think we should go away from the AbstractPolygeneTest & Co, and redo that
with Junit Rules.
That way we get @Rule and @ClassRule semantics for free.

I made a small test


public class Qi383Test
{
    @Rule
    public PolygeneSingletonRule runtime = new PolygeneSingletonRule()
    {
        @Override
        public void assemble( ModuleAssembly module )
            throws AssemblyException
        {
            module.entities( Car.class );
            new EntityTestAssembler().assemble( module );
        }
    };


and added a "runtime." where ever the previous test case was referencing
fields in the super class.

We could then create additional rules with layered architecture, and then
it should be possible to fit all tests into both single module and layered
set ups, with relatively small effort (I think).

If no one objects violently, I want to make this change before 3.0. Should
be ready today.


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

Re: Junit Rules

[Niclas Hedhman <ni...@hedhman.org>]

Forget this...

JUnit 5 is around the corner and the Rules support is somewhat withdrawn.
They intend to support it with adapters, but there might be some issue as
the extension models are different. The docs say;

<quote>

6.3. Limited JUnit 4 Rule Support

As stated above, JUnit Jupiter does not and will not support JUnit 4 rules
natively. The JUnit team realizes, however, that many organizations,
especially large ones, are likely to have large JUnit 4 codebases including
custom rules. To serve these organizations and enable a gradual migration
path the JUnit team has decided to support a selection of JUnit 4 rules
verbatim within JUnit Jupiter. This support is based on adapters and is
limited to those rules that are semantically compatible to the JUnit
Jupiter extension model, i.e. those that do not completely change the
overall execution flow of the test.

</quote>


I have been browsing JUnit 5 docs for a short while now, and it seems that
they have been able to separate things rather nicely and loads of support
for extensions in all kinds of directions. It looks pretty good, especially
if you have looked at the internal mess of JUnit 3.x and the somewhat
better 4.x.

We actually have a whole bunch of options on what test support we can
provide to our users, including the most drastic one; our own TestEngine
which would allow Polygene approach to testing and yet remain compatible
with all JUnit tooling out there. I find this very very interesting and
will probably take a stab at it soon enough.

But there are lesser steps that are also interesting. So, Rules and Runners
are GONE, well, in principle. Still supported as mentioned above. It is now
a single Extension API. Extensions are declared on test classes or methods,
and somewhat similar to our composition approach. Extensions are intended
to be composable;


@ExtendWith({ LayeredApplicationExtension.class, DockerExtension.class
})class MyTests {
    // ...
}


That could be that a Layered Polygene application is established and a
Docker extension will set up needed containers.

An Extension then implements the callback interfaces that it is interested
in. And the lifecycle is much better specified, instead of that static
parts in JUnit4, it is now all in objects.


[image: Inline image 1]

This should make it rather easy to instantiate a Polygene runtime, make the
testcase an object within the runtime and inject the Polygene into the
testcase itself, either once for all tests or per test.


And yes, JUnit5 requires Java 8 !


Cheers
Niclas


On Mon, Jun 12, 2017 at 12:10 PM, Niclas Hedhman <ni...@hedhman.org> wrote:

> Hi,
>
> I think we should go away from the AbstractPolygeneTest & Co, and redo
> that with Junit Rules.
> That way we get @Rule and @ClassRule semantics for free.
>
> I made a small test
>
>
> public class Qi383Test
> {
>     @Rule
>     public PolygeneSingletonRule runtime = new PolygeneSingletonRule()
>     {
>         @Override
>         public void assemble( ModuleAssembly module )
>             throws AssemblyException
>         {
>             module.entities( Car.class );
>             new EntityTestAssembler().assemble( module );
>         }
>     };
>
>
> and added a "runtime." where ever the previous test case was referencing
> fields in the super class.
>
> We could then create additional rules with layered architecture, and then
> it should be possible to fit all tests into both single module and layered
> set ups, with relatively small effort (I think).
>
> If no one objects violently, I want to make this change before 3.0. Should
> be ready today.
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://polygene.apache.org - New Energy for Java
>



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