How can I perform some tests (it() calls) about an object under test, then call a method() on it, and then perform some more tests on the object's state modified by method()?
The problem is that a call to it() schedules the actual assertion to be performed much later, and as a result of this ALL the tests will actually run after the call to method(), including those that I want to run before that call. How to overcome this?
Related
I wonder how could I write spring tests to assert logic chain which is triggered by 'SourcePollingChannelAdapter'.
What comes to my mind:
use Thread.sleep() which is really bad idea for tests
Have another test version of spring context where I will replace all pollable channels with direct ones. This requires much work.
Are there any common ways to force trigger poller within test?
Typically we use QueueChannel in our tests and wait for the messages via its receive(10000) method. This way, independently of the source of data, our test method thread is blocked until data has arrived.
The SourcePollingChannelAdapter is triggered by the TaskScheduler, therefore the whole flow logic is done within a separate thread from the test method. I mean that your idea about replacing channels won't help. The Thread.sleep() might have value, but QueueChannel.receive(10000) is much reliable because we really maximum wait only for those 10 seconds.
Another way to block test-case comes from the standard CountDownLatch, which you would countDown() somewhere in the flow and wait for it in the test method.
There is some other way to test: have some loop with short sleep period in between iteration and check some condition to exit and verify. That may be useful in case of poller and database in the end. So, we would perform SELECT in that loop until desired state.
You can find some additional info in the Reference Manual.
I am a beginner in SAP ABAP. I am debugging an asynchronous RFC (parallel processing). I have put a break-point in the calling portion of the RFC, an external break-point inside the RFC and an external break point in the form which is called at the end of task through perform. I am able to debug the RFC FM.
Another session opens up. But I am not able to debug the perform which is called after end of task. After the RFC is debugged, the control returns to the calling point of the FM. it doesn't go inside the form. When all the iterations are finished, then at the end it goes inside the perform. Why so? shouldn't the perform be executed in parallel?
Inside the perform I have written like RECEIVE RESULTS FROM FUNCTION XXX. But the debugger control is not going inside the perform after returning from the RFC.
You have given very little information on the overall program flow, but there's a part of the documentation that might be relevant to your case:
A prerequisite for the execution of a registered callback routine is
that the calling program still exists in its internal session when
the remote function is terminated. It is then executed here at the
next change of the work process in a roll-in. If the program was
terminated or is located on the stack as part of a call sequence, the
callback routine is not executed.
[...]
The time when the callback routines are executed can be programmed
explicitly or be reached implicitly:
The statement WAIT FOR ASYNCHRONOUS TASKS is used for explicit programming. As specified by a condition, this statement changes the
work process and hence executes the callback routines registered up to
this time. It waits for as many registered routines to end until the
condition is met (the maximum wait time can be restricted). Explicit
programming is recommended whenever the results of the remote function
are required in the current program.
If the results of the remote function are not required in the current program, the time at which the callback routines are executed
can also be determined by an implicit change of the work process (for
example, at the end of a dialog step). This can be a good idea, for
example, in GUI scenarios in which uses of WAIT are not wanted. In
this case, it must be ensured that the work process changes before the
program is ended. There is also a risk that, if the work process is
changed implicitly, not all callback routines are registered in time.
It is likely that the program issuing the call and registering the callback routine is either terminated or does not issue a WAIT FOR ASYNCHRONOUS TASKS so that the callback is only executed on the next roll-in.
Re-reading your question, you apparently assume that the callback routine will be executed in parallel to the program that has registered it. That is not the case, ABAP is not multi-threaded.
I use jasmine to test my server side code and i need to run tests in serial, not in parallel.
My tests need to make CRUD operation in database. If test are executed in parallel i can't ensure that the database is in a good context for my test
Unless you explicitly choose to create asynchronous tests in Jasmine, everything in Jasmine happens sequentially, in the sense that one test runs only after its preceding test has finished. And if you do write asynchronous tests, then parts of your single test may run in parallel, but you still have the constraint that one test runs only after its preceding test has finished.
However, there are a couple caveats to be aware of:
In an async test if your code exceeds Jasmine's timeout period, you might still have code running when Jasmine decides to give up on that test and proceed to the next. (Thanks to #Gregg for this tip; see this answer.)
"JavaScript is usually considered to have a single thread of execution... however, in reality this isn't quite true, in sneaky nasty ways." I am quoting #bobince from this answer.
According to Mocha documentation, "Mocha tests run serially" which means in the order they are defined.
My question is: what makes async (with done callback) tests different than sync?
You tell Mocha that a test is asynchronous by passing to the it call a function that takes an argument (traditionally named done). Mocha will then call this function with a first argument which is a callback that you must call to tell Mocha the test is over.
The only difference between an asynchronous test and a synchronous one is that for an asynchronous test Mocha will wait for the done callback to be called before moving on to the next test. If the test is deemed to be synchronous, then Mocha will move on to the next test as soon as the function you passed to it returns. If Mocha were to do this with asynchronous tests too then it would not be able to associate unhandled exceptions with the appropriate test.
I've written many unit tests in a file.
The problem is they don't run in order.
I first make an entry to the database in one method and delete the same entry in another method.
Insert() appears before Remove() in my test file.
But still Remove() runs first and hence I am not able to execute the test cases effectively since it won't find the entry. Reason could be Remove() takes less execution time than Insert()
Can we set the sequence to the test cases?
You can prefix the test names with character alphabetically
like
aTestSomething
bTestAnotherThing
:)
better way
How to order methods of execution using Visual Studio to do integration testing?