Field tests ‐ Introduction

• Alpha Tested Features

Introduction

Thanks for supporting this project by running tests.

Combinatoric explosion - need help

We are extremely grateful for each test you can provide since we deal with a variant of a combinatoric explosion. Take our basic tests. There are just peer A and B. One sends a message. This message is expected to be received by the other peer after an ASAP encounter. Easy. ASAP already implies variants: a message can be sent before and during an encounter. We have two variants. A or B sends a message. Isn't that the same? Think so but better safe than sorry. We have four variants in this case.

It's getting worse. Take test A1. Peer A sends a message during an encounter with Peer B. One simple test. Both peers can run on a single computer like e.g. Windows, Ubuntu or Mac. Makes 3 variants. Peers can run on different machines same OS in a LAN. Makes 3 more tests. A can run on Windows, B on Ubuntu etc. pp. You see the picture. Finally, peers can run on different machines and in different local networks.

Any helping hand is welcome.

Test structure

Here is the general test structure: Test scripts are part of this git repository. The script folder comprises all test scrips. Note: Test are software and have version. Version 1 of a basic test A1 folder contains just two scripes - each for peer A and B. This page offers a complete list of all test scripts available.

Test results are also part of this repository. Folder testRuns contains test results from successful tests. testRunsFailed is meant to store logs from failed tests. There should be a folder for each test scenario/version. Subfolders are the storage for logs produced by a tests. The failed test folder is the source for our debugging session.

How to run a test.

First of all, take your time. Tests are meant to find bugs in a software. Finding bugs in tests tends to be more difficult. The most annoying problems are produced when the test environment is not set up accordingly. Empty folders are usually required to run a test. This software has a memory and that is stored in files.

Take your time :)

You better have got writing privileges in the test-folder.

Preparation:

• pick es test scenario in the test&plan (see tables below)
• create an empty directory
• make sure you have test the most recent release in your directory
• copy test script(s) into your empty directory - tables below provide a more specific reference to the required scripts

Execution:

• launch each peer, namely the messenger cli like this: cat peerA.txt | java -jar SharkNetMessengerCLI.jar Alice.
• There are at least two peers involved: make sure your peers start (more or less) synchronously - adjust wait periods if necessary

Checking results

• document your result by adding a line in the test&plan document; commit & push this file
• Add a new folder in the testRunsFailed- or testRuns
• upload logs
• commit & push

Thank your very much

Alpha Tested Features

Version 1.0

Version 1.0 proofs to be stable in routing in different configurations, on different networks and OS with different messages sizes.

Covered tests: Basic Version 1.0, Complex Version 1.0, Hub Version 1.0