summaryrefslogtreecommitdiff
path: root/clients/tests/test-client.check-on-disk/test_002-007.expected
diff options
context:
space:
mode:
authorThomas Haller <thaller@redhat.com>2018-06-07 17:42:31 +0200
committerThomas Haller <thaller@redhat.com>2018-06-11 11:20:31 +0200
commitdd2da759de7d0b80d2328ba9687f3a5a263723c0 (patch)
tree5b946fa22465f9572c6252c7dbcb0b9d5dba1c62 /clients/tests/test-client.check-on-disk/test_002-007.expected
parentac8f7869878b2ed8d2b882cb14b21fc7b6ef2ffa (diff)
downloadNetworkManager-dd2da759de7d0b80d2328ba9687f3a5a263723c0.tar.gz
clients/tests: seed generated numbers for test-networkmanager-service.py
At several places, "test-networkmanager-service.py" uses generated numbers with a defined seed. For example, generated connection's UUID is generated in a predictable, but randomized way (if you forgive the inprecise use of the word "random" in context of using a deterministic seed). Aside the connection's UUID, this becomes more interesting in the next commit where the stub server generates a list of IP and DHCP settings in a predictable randomized way. For "clients/tests" we spawn the test service multiple times, but also create similar environments by calling init_001(). This is done for convenience, where out of lazyness all the tests share one setup. But it's still a good idea that these tests generate slightly different setups, wherever applicable. this increases the possible setups which get tested. For example, the number of static IPv4 addresses (the following commit) is interested to explicitly test for zero or a non-zero number of addresses. If all tests happen to use the same seed, the tests are expected to also generate the same number of addresses, and we miss an opportunity to hit interesting test cases. There is still no guarantee that all interesting cases are hit, the chances are just better. The approach of generating the setup randomly, does not preclude that the stub-server allows to explicitly configure the setup. However, due to the sheer number of combinations that might be interesting to test, it's much simpler to rely on some randomization and have the justifid hope we catch interesting cases. Also in terms of runtime of the test, the cli unit tests should complete within few seconds. Testing every combination would result in huge tests and long runtimes. Also, the patch refactors generating random numbers in "test-networkmanager-service.py". For example, it introduces Util.RandomSeed(), which can be used to generate a sequence of different random numbers. It works by having an internal state and a counter which is combined to chain the seed and generate different numbers on each call.
Diffstat (limited to 'clients/tests/test-client.check-on-disk/test_002-007.expected')
-rw-r--r--clients/tests/test-client.check-on-disk/test_002-007.expected18
1 files changed, 9 insertions, 9 deletions
diff --git a/clients/tests/test-client.check-on-disk/test_002-007.expected b/clients/tests/test-client.check-on-disk/test_002-007.expected
index 6e71d66f11..a99c1cb9be 100644
--- a/clients/tests/test-client.check-on-disk/test_002-007.expected
+++ b/clients/tests/test-client.check-on-disk/test_002-007.expected
@@ -1,4 +1,4 @@
-location: clients/tests/test-client.py:683:test_002()/7
+location: clients/tests/test-client.py:686:test_002()/7
cmd: $NMCLI -f AP -mode multiline d show wlan0
lang: C
returncode: 0
@@ -9,24 +9,24 @@ AP[1].SSID: wlan0-ap-3
AP[1].MODE: Infra
AP[1].CHAN: 1
AP[1].RATE: 54 Mbit/s
-AP[1].SIGNAL: 88
-AP[1].BARS: ****
+AP[1].SIGNAL: 55
+AP[1].BARS: **
AP[1].SECURITY: WPA1 WPA2
AP[2].IN-USE:
-AP[2].SSID: wlan0-ap-2
+AP[2].SSID: wlan0-ap-1
AP[2].MODE: Infra
AP[2].CHAN: 1
AP[2].RATE: 54 Mbit/s
-AP[2].SIGNAL: 61
-AP[2].BARS: ***
+AP[2].SIGNAL: 44
+AP[2].BARS: **
AP[2].SECURITY: WPA1 WPA2
AP[3].IN-USE:
-AP[3].SSID: wlan0-ap-1
+AP[3].SSID: wlan0-ap-2
AP[3].MODE: Infra
AP[3].CHAN: 1
AP[3].RATE: 54 Mbit/s
-AP[3].SIGNAL: 29
-AP[3].BARS: *
+AP[3].SIGNAL: 34
+AP[3].BARS: **
AP[3].SECURITY: WPA1 WPA2
<<<