Hi,
xtext.testing does have utilities for Junit5. But I’ve serious doubts whether a migration of the tests would pay off. What is the real problem you are tackling? Certainly not the cost of object initialization, is it?
To be honest: I was simply curious. I have found this new feature in JUnit 5 and I was wondering what effect that might have. I did a quick research via Google and didn’t find any information regarding performance. I mean, depending on the tests it might pay off: Not so much the object initialization itself, but setting all the fields etc. We have a lot of tests which use a lot of injected stuff, but the tests are perfectly isolated otherwise. I was just curious whether a per class life cycle would have an effect.
Cheers, Jens
Follow up:
By circumventing the target platform I was able to quickly use Junit 5 (Jupiter). And I run into a major problem: Junit 5 (Juptiter) does not support @RunWith anymore. Instead there is a new concept (@ExtendWith). Is it possible to run Xtext stuff with Junit 5?
Cheers,
Jens
> On 23. May 2019, at 18:49, Jens von Pilgrim <developer@xxxxxxxxx> wrote:
>
>
> Dear Colleagues,
>
> I’m a bit confused… probably easy to solve for you.
>
> I haven’t worked with “plain” JUnit for a long time, since we always use the Xtext runner and stuff like that. So I totally forgot the default test life cycle: JUnit creates a new test instance per test method. This is also not changed by our runners, is it? Somehow I thought that we use a per class life cycle, but this is not the case.
>
> With JUnit 5, it is easy to introduce such a life cylce (with annotation @TestInstance(Lifecycle.PER_CLASS)). This is new in JUnit 5, I haven't found this in JUnit 4.
> Now I have several questions:
>
> 1. Would it make sense to use JUnit 5 instead of 4?
> 2. If we would like to use JUnit 5 — how do we configure that? I have only found JUnit 4 in our target platform and I’m not quite sure how to set that up — we urgently need more documentation about the target platform. Or did I only miss it?
> 3. Would it make sense to use the Lifecycle.PER_CLASS, as e.g. the dependency injection is performed only once (and some injected things are not singletons)? And many of our tests seem to be isolated anyway, so it would speed up things it we wouldn’t need to create a new test instance for each test. Any ideas about performance improvement? (I wasn’t able to test it since I wasn’t able to replace JUnit 4 with 5)
>
> Cheers,
> Jens
> _______________________________________________
> n4js-dev mailing list
> n4js-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/n4js-dev
_______________________________________________
n4js-dev mailing list
n4js-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/n4js-dev
-- --
Sebastian Zarnekow
Saskatoon Str 33 | 14513 Teltow
Tel: 0151 / 1739 6724
_______________________________________________ n4js-dev mailing list n4js-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/n4js-dev
|
