I am writting test for GWT, but I did not find any example of fireEvent test.
Can any one help me?
I have event that has handler which put some current variable on the list. I would like to test the method that fires an event?
Does this make any sense to anyone?
Do we need such Unit tests?
I would split up the tests
Test if the event is fired
Test the method that puts a variable on a list by just calling the method directly
Regarding 1: You can use com.google.gwt.event.shared.testing.CountingEventBus and then use getCount(GwtEvent.Type) to check how many times the event was fired, see here for more infos.
If you pass data in your event object and you want to test that you can create your own fake EventBus (see this and this test for more infos)
You can also test that the your handler is properly executed when you fire the event. Just fire the event on the EventBus and use an assertion for the list (see this test for an example)
Related
I am running some simple performance tests with JUnit 4 and using Jenkin's perfReport so that I can generate a performance report.
While running these tests, I noticed that the test method execution includes execution time of methods annotated with JUnit 4's #before and #after.
I came across a similar post: Exclude #Before method duration from JUnit test time, however I require my output format in a JUnit-style report since the Jenkin's perfReport parses JUnit-style format only.
As such, is there a way to exclude the execution time of these annotated methods?
I solved it by performing the following:
Extending the BlockJUnit4Runner
Overriding the runChild() method, as this is where test notifiers are received
Writing a custom runLeaf() method, as this is where the test notifiers are fired to notify the test has started or stopped.
Overriding the methodInvoker() method, as this is where the test method is invoked
Creating a new Statement class that functionally, performs the same set of actions as a invokeMethod() statement object created in methodInvoker. This class however, receives the test notifier, thus allow you to control how and when the test is considered to have started.
One issue of the above approach is that you will need to extract code sections that help to run JUnit rules, in order to preserve rule execution as these methods are strangely private.
I can't find any ressources explaining what exactly the difference between BeforeEachCallback and BeforeTestExecutionCallback in the JUnit Jupiter extension model is. (I am of course also interested in the "After"-variants)
To my understanding, the following timeline describes what is happening:
BeforeEach - BeforeTestExecution - Actual execution of the test - AfterTestExecution - AfterEach
I suppose that BeforeTestExecution exists so you can execute code after all the BeforeEach callbacks have been worked on but before the actual test execution. However this is still unclear to me, because everyone could just use BeforeTestExecution instead of BeforeEach and the order of execution of these callbacks is random again.
So what is BeforeTestExecution exactly for and what happens if you use this callback in multiple extensions at the same time?
The Javadocs (here and here) don't make a clear distinction between them but the JUnit5 docs include the following:
BeforeTestExecutionCallback and AfterTestExecutionCallback define the APIs for Extensions that wish to add behavior that will be executed immediately before and immediately after a test method is executed, respectively. As such, these callbacks are well suited for timing, tracing, and similar use cases. If you need to implement callbacks that are invoked around #BeforeEach and #AfterEach methods, implement BeforeEachCallback and AfterEachCallback instead.
So, if you want to wrap just the test execution without any of the setup then use BeforeTestExecutionCallback. The docs go on to suggest timing and logging test execution as possible use cases for BeforeTestExecutionCallback.
I have a snippet of code that I want to unit test.
this.vertx.eventBus().consumer(VERTICLE_ID).toObservable()
.subscribe(msg -> doSomethingCool());
and my consumer method:
private void doSomethingCool(){
// Some cool stuff.
}
Now I want to unit test doSomethingCool() without using powermockito (I want to have code coverage) and I dont want to make my method visible (public). How can I do that? Any hook in vertx to do that ?
It actually hard to tell how you should write your test if nothing is known about the purpose of doSomethingCool
Does it return a value? (i.e. via msg.reply())
Does it modify state of the Verticle? or global state?
Does it make a downstream call?
Does your method invoke a handler once it's done with whatever it does?
A unit test should verify an observable result. So write your unit test to verify one of these outcomes.
In case a handler is invoked, you could work with the vertxunit TestContext and count down an async.
... and stay away from Powermockito.
My situation in short: I want to perform parallel tests. Lets say I have 4 credential pairs and 32 tests that will be run in 8 parallel threads (on parallel method level). So I have standart producer-consumer situation but beetween parallel tests.
My idea is to have list of credential objects (on which I will synchronize test threads in "beforeMethod" phase). First 4 threads will get their credentials and remove them from list. All other threads will see empty list and wait ON it.
First test that will finish its execution and will add used credentials back to list on "afterMethod" phase and invoke notify on this list, and so on. But the problem is that I dont have any proper place where I can locate this list of credentials + I want to use simple "mvn test" for starting this process. Any ideas how can I add such synchronization? If there is some similar functionality in TestNG - please tell.
Solved. Main problem was to override TestNG lifecycle + save maven test management. So I started to dig TestNG source code and came to next solution:
Extend IExecutionListener which will store needed data (queue) as a public static final member.
Same interface IExecutionListener participates in TestNG lifecycle: it has lifecycle callbacks onExecutionStart and onExecutionFinish. First one were used to populate queue with credentials from file, and second one is to ease GC work - clean this queue.
Populated queue was used inside of init method annotated with #BeforeMethod. Note: do not store value from queue as a plain member as you'll face overwriting of this member from different threads that performs tests from same class but different tests. Use ThreadLocal to provide thread isolation of this variable.
Special data structure that serves good for my case is BlockingQueue (in LinkedBlockingQueue implementation) with take and put as getter/setter.
Also do not forget to add your custom listener to your xml
I have a Settable Future object "temp" which has a context set to it. Also temp.addListener(new Runnable{...}) method is called, basically registering a listener to it. However eventually if any exception comes up then temp.setException() is called. If the setException is called will the listener be de-registered or will the context be cleared (basically will the Settable Future object be damaged after exception is set)?
The flow of code is something like this :-
temp.setContext({temp.set(//some value is set if everything goes right) || temp.setException(//set exception if something comes up)});
temp.addListener(new Runnable{ run(){temp.get()}})
When you call setException(), the ListenableFuture will run its listener. If you want to write code that will not be run in that case, you can use Futures.addCallback instead of addListener. (addCallback lets you specify code to be run only in case of success or only in case of failure.)
As for what happens with the context: The context isn't part of the ListenableFuture API. I don't know if it was added by you or another library. You'd have to consult that class to find out how it behaves.