Is there a more elegant approach to that? I'm afraid, however, that such approach would be difficult to understand (and require a custom test runner). I thought about using for each test a decorator with the names of the tests which should run before it-a bit like dependency management, where every package can tell that it needs some other packages to be installed. Instead of just adding the test, I need to add it first, and then go and change the names of all successive tests. This creates a problem when I need to insert a test in the middle of the chain. In order to determine the order, I prefix the names of the tests with a number: def test_07_recover_file(self):
And I can't test the third step before performing the second one, because I cannot resume an upload which never started in the first place. Here, the order is crucial: I can't test the recovery step, if I haven't made the backup in the first place. The client will ask the API to delete a file which was already deleted, receive a HTTP 404, and is expected to handle it correctly. Perform a backup, and while doing so, crash intentionally to simulate a situation where the file was deleted remotely, but the local client doesn't know that. Ensure the upload of the file from the previous step is resumed. Perform a new backup, but simulate a situation where the API crashed in the middle.
MULTIPLE TESTING VS SEQUENTIAL TESTING CODE
System tests run on a live API in order to check high-level regressions in the code of the client which made it somehow incompatible with the API. Some system tests consist of a series of steps for a given scenario, and they need to run in a specific order.įor example, I have a client application which performs offsite backups. I'm using unittest framework to run Python tests.
0 kommentar(er)
