I'm using DynamicNode very successfully in a framework that dynamically generates tests and executes them.
Now I have a need to execute some code after all DynamicNode collections have executed. This can mean that I have a single JUnit5 class with multiple methods that return Iterable<DynamicNode>, but I want to run something only after all the test methods have completed.
Is there a way to do this automatically ?
EDIT: ideally I would like my framework to inject the code to be executed automatically, without the user needing to add a #AfterAll annotation on a method and write some extra code.
Each method that is annotated with #TestFactory takes part in the default lifecycle. That means in your case an #AfterAll annotated method should do the trick.
#AfterAll
Denotes that the annotated method should be executed after all
#Test, #RepeatedTest, #ParameterizedTest, and #TestFactory
methods in the current class; analogous to JUnit 4’s #AfterClass.
Such methods are inherited (unless they are hidden or overridden) and
must be static (unless the "per-class" test instance lifecycle is
used).
Copied from https://junit.org/junit5/docs/current/user-guide/#writing-tests-annotations
Related
User guide contains following:
Usually, an extension is instantiated only once.
It's not very clear when extension can be instantiated many times? I'm supporting test suite with multiple extensions and every extension stores it's state in class fields. Everything works fine, but can I rely on this or should I refactor this code to use ExtensionContext.Store?
Usually, an extension is instantiated only once. So the question becomes relevant: How do you keep the state from one invocation of an extension to the next?
I think this sentence shall highlight that the same instance of an extension might be re-used for multiple tests. I doubt that the instance might be replaced in the middle of a test.
Multiple instances of an extension might be instantiated when a test uses programmatic extension registration (with #RegisterExtension). In such case, the test class creates its own instance of the extension. JUnit cannot reuse this instance in other test classes. But an instance created by declarative extension registration (with #ExtendWith) might be used for multiple test classes.
I have bunch of functional tests based on Spock and Geb. I want to perform some actions before and after execution of these tests. So I created global extension and added required functionality to start() and stop() methods of that extension. But the problem is that start/stop methods are invoked before/after each Spock spec though Spock documentation (http://spockframework.org/spock/docs/1.1/all_in_one.html#_global_extensions) states:
start() This is called once at the very start of the Spock execution
stop() This is called once at the very end of the Spock execution
Do I do something wrong or Spock documentation is incorrect about behaviour of these methods?
#MantasG Spock implements a JUnit Runner and does not control how it is executed. Global extensions are managed in a RunContext which is kept in a ThreadLocal. If surefire uses multiple threads to execute Tests then this will create multiple instances of RunContext each with their own list of global extensions. If you are using an EmbeddedSpecRunner then this would also create a new isolated context.
This context will stay around until the thread dies. It would be
more accurate to remove the context once the test run has finished,
but the JUnit Runner SPI doesn't provide an adequate hook. That
said, since most environments fork a new JVM for each test run, this
shouldn't be much of a problem in practice.
Depending on what you want to do there are other ways:
you can use a JUnitRunListener and use the testRunStarted/testRunFinished hooks. Note that you need to register this via surefire.
If you really want to run only once, then you could use failsafe instead of surefire and use the pre- and postintegration goals.
You could hack something using a static fields and a counter for each start/stop call and perform your start action if the counter is 0 and perform your stop action once the counter reaches 0. Of course you'll need to make this thread safe.
Note that surefire also supports forking multiple JVMs and this will also impact options 1 and 3.
I believe Spock is invoked at the start of every Testing Spec in your testing Suite, so start and stop are run with every one of those executions
I think you might want to take a look at the Fixture Methods found in the same doc you linked in the question:
http://spockframework.org/spock/docs/1.1/all_in_one.html#_specification
I am using AspectJ and Load-time weaving to trace methods calls in an arbitrary java program. I can trace all calls using the standard:
call(* *.*(..))
But what I now trying to do is separate out calls to the native java libraries and any application code:
nativeCalls(): !within(MethodTracer) && call(* java..*.*(..));
appCalls(): !within(MethodTracer) && call(* *.*(..)) && !call(* java..*.*(..));
The issue is that the nativeCalls() pointcut is picking out calls to application classes that inherit from native java classes, even though the signatures do not start with java.lang. or java.util, etc.
For example:
If I have a class tetris.GameComponent that inherits from java.awt.Component, my nativeCalls() pointcut will pick out tetris.GameComponent.getBackground() when the method is actually implemented in java.awt.Component.getBackground().
Is there a way to have my nativeCalls() pointcut ignore the calls to inherited methods?
I hope this is clear. I can provide additional info if necessary. Thanks for any help that can be provided.
Actually I have no idea why you want to exclude those inherited method calls from your trace because IMO it is important or at least interesting to know if a method was called on one of your classes, even if that method was defined in a JDK super class.
But anyway, the answer is no, you cannot exclude calls to JDK methods from your nativeCalls() pointcut if those calls are actually made upon target objects typed to one of your application classes. At the time the call is made, AspectJ does not know how the JVM will resolve the polymorphism. There can be several cases:
Call to Foo.aaa(), existing method Foo.aaa() is executed. This is the simple case where a called method actually exists.
Call to Foo.bbb(), inherited method Base.bbb() is executed (polymorphism). This is the case you want to exclude, but you cannot because the fact that a base method is called will only be known when the method is executed. Furthermore, if Base is a JDK class, you cannot even intercept its method executions with AspectJ.
Call to Base.ccc(), non-overridden method Base.ccc() is executed. This can happen if you directly create an instance of Base or also if you assign/cast a Foo instance to a variable typed Base, e.g. Base obj = new Foo(), and call obj.ccc() which has not been overridden by Foo.
Call to Base.ddd(), overridden method Foo.ddd() is executed (polmorphism). This also happens if you assign/cast a Foo instance to a variable typed Base, e.g. Base obj = new Foo(), and call obj.ddd() which has been overridden by Foo.
So much for not being able to easily exclude the polymorphism stuff when calling inherited JDK method.
Now the other way around: You can easily intercept execution() instead of call() upon your application classes and take advantage of the fact that JDK method executions cannot be intercepted anyway: pointcut appMethod() : execution(* *(..));
I wonder if there is a way using OCMock can invoke a class method twice separately as if the app runs two times, but in fact, only once.
I want to test a class method. Due to some static variables inside the method, the method will keep its behavior all the time once it's called. Thus I can't test different behaviors at one time.
And of course, I can't add anything else to the class if the purpose is only for testing.
There is not a way to alter statically declared variables with OCMock without exposing them via Objective-C methods. You say "of course" you can't add anything to the class just for testing purpose, but this is not universally accepted. There is a an entire school of thought that believes your code itself should be designed to be tested.
- (NSInteger)someStatic
{
static NSInteger _someStatic = 42;
return _someStatic;
}
If you used a pattern like that that (for example, there may be better ones) you could mock your static. While this will add a method call anywhere the static is used, you may find it more important to have comprehensive testing.
OCMock version 2.1 has support for mocking class methods:
OCMock 2.1 released
15 March 2013
New release (2.1) which adds support for stubbing class methods and includes many contributed bug fixes. This release is compatible with Xcode 4.5/4.6.
The "Features" page on their website give some examples on how to mock a class method:
Class methods
[[[mock stub] andReturn:aValue] someClassMethod]
Tells the mock object that when someClassMethod is called on the class for which the mock object was created it should return aValue. This is the same syntax that is used to stub instance methods.
In cases where a class method should be stubbed but the class also has an instance method with the same name as the class method, the intent to mock the class method must be made explicit:
[[[[mock stub] classMethod] andReturn:aValue] aMethod]
The class can be returned to its original state, i.e. all stubs will be removed:
[mock stopMocking]
This is only necessary if the original state must be restored before the end of the test. The mock automatically calls stopMocking during its own deallocation.
Note: If the mock object that added a stubbed class method is not deallocated the stubbed method will persist across tests. If multiple mock objects manipulate the same class at the same time the behaviour is undefined.
We use RhinoMocks. I have a type into whose constructor 9 types are injected. I'd like a way of automocking the type, but being able to detect a particular method invocation on one of the injected objects (i.e. I only care about a single method invocation on one of the injected objects).
Is this possible, or do I have to manually inject all the mock objects into the constructor?
I haven't seen any frameworks that would auto-create these mocks for you. You can do it in your [SetUp] method, so at least the tests will not be cluttered with boilerplate code.
I need to check out http://autofixture.codeplex.com/. Its not really container specific, there is an extension for rhino mocks. Disclaimer: I haven't tried autofixture yet.