-
Notifications
You must be signed in to change notification settings - Fork 6
TestSupport
The simplest thinkable ASAP application supports only single connection at given moment in time. In other word: The ASAP peer inside the application is ask to deal only with at most one connection.
That's good for unit tests. It is - unfortunately - reality in some mobile phone Bluetooth environments. We come back later to this point.
Let's talk about test support. Real applications will support at least multi connections.
Testing is crucial. This framework offers a specific test class to support ASAP unit tests.
package net.sharksystem.asap.apps.testsupport;
...
public class ASAPTestPeerFS extends ASAPPeerFS {..}
ASAPTestPeerFS is an ASAPPeer with some additional methods. Here comes some code which can and is used as template for dozens of tests. This was taken from Point2Point2Test2. Have look.
ASAPTestPeerFS aliceSimplePeer = new ASAPTestPeerFS(aliceID, aliceDirectory, formats);
ASAPTestPeerFS bobSimplePeer = new ASAPTestPeerFS(bobID, bobDirectory, formats);
// do something before an encounter
// ...
aliceSimplePeer.startEncounter(TestHelper.getPortNumber(), bobSimplePeer);
// do something during an encounter
// ...
// give both peers some time to run their applications
Thread.sleep(100);
// check for expected results
// ...
aliceSimplePeer.stopEncounter(bobSimplePeer);
Two peer are created. They store their data with a filesystem and require an id, a directory and supported formats.
Method startEncounter
requires a port number and a peer object. Now, A TCP connection (using localhost
as IP address) is created. This local loop TCP connection has got two stream pairs on each side. aliceSimplePeer
is asked to handle that connection from on side and bobSimplePeer
from the other side. Connection estasblishment is hidden from developer implementing a test. You can have a look, though.
Actually, that's not even a fake. Both peers run an ASAP encounter over a real TCP connection. That connection runs in the same process, though. That can be a challenge. We discovered race conditions which are very unlikely in a real environment where peers run on different machines. Data round-trip time is extremely small.
stopEncounter
closes that TCP connection. The ASAP session is over. This approach works fine and is recommended for functional unit tests. It will not work in real applications.
Real distributed applications hardly run in the same process. Maybe cloud apps do but that's far out of scope of this documentation.