diff options
author | Thomas Haller <thaller@redhat.com> | 2018-06-07 17:42:31 +0200 |
---|---|---|
committer | Thomas Haller <thaller@redhat.com> | 2018-06-11 11:20:31 +0200 |
commit | dd2da759de7d0b80d2328ba9687f3a5a263723c0 (patch) | |
tree | 5b946fa22465f9572c6252c7dbcb0b9d5dba1c62 /clients/tests/test-client.check-on-disk/test_002-007.expected | |
parent | ac8f7869878b2ed8d2b882cb14b21fc7b6ef2ffa (diff) | |
download | NetworkManager-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.expected | 18 |
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 <<< |