Testing in this project is a big part of making sure that the implementation is correct and robust. That is why we decided to spend so much time on it.
Testing is nessicary, almost essential. We need to know our code is correct, robust all the time. That is why testing with gitlab is so good. Every time we commit we can have our integration and unittest run. This is a fantasic workflow to get into. But not all code can be tested with it.
We found because our project was hardware specific we couldn’t test certain aspects that involved the hardware interfaces such as the wireless card for sniffing packets. We would have to test these by hand. This is not always the best option because, humans are lazy, the methods of testing may not be the same every time, and a whole range of other issues. In hindsight we should have scripted the method more to avoid some of these descrepencies between tests. But we are going to loosely document here, how we went about testing.
For the ssid detection plugin, we had to trigger the plugin by creating a hotspot with a protected name and see if it sent us and error. This was pretty easy to test, and there was not much that could have changed. The only problem would be if the subject was too far away from the node and determined it didn’t work if it did.
The next test was access point metric collection. This collects signals of all the access points in range. We do this by finding the beacon packets and collecting the signal with scapy. To test this it was a little tricker. We first had to find what access points were around, checking manualy. We also had to check that the metric were accurate. For this we had to also manualy look through tools to find the signal and checking that metric in the database at that time. It was only figured out because of this testing that our interface card can only pick up 2.4mhz traffic and not 5mhz traffic. This was unfortunate but did not stop us.