Uploaded image for project: 'Mender'
  1. Mender
  2. MEN-3841

Acceptance tests for docker-compose Update Module




      Exact method of testing this is somewhat up to the implementer to decide what is easiest, but which still provides good enough coverage. These are my suggestions:

      • Treat the Gitlab "dind" container as the "device", since we can do Docker operations there.
        • For local testing, probably it is needed to execute the test inside a local dind container which can do Docker operations
        • One of the tests handles rootfs support, which will be missing, but all we need is the entry in mender.conf, so this can be faked.
      • Use mender-test-containers for more comprehensive testing.

      Acceptance criteria:

      • Acceptance tests created for Update Module in MEN-3839, using a semi-real device.
      • Must test at least:
        • Successful update from nothing = containers running afterwards.
        • Unsuccessful update from nothing = nothing running afterwards.
        • Successful update from previous containers = containers run afterwards, and none of the old ones do.
          • It's a good idea to have one container less in the new docker-compose file, to make sure that the old one being obsoleted is not being orphaned.
        • Unsuccessful update from previous containers = rollback works, and the old containers run afterwards, none of the new ones.
        • After successful update, check that old digest is not available in docker images --digest anymore.
      • Everything passing in Gitlab


          Issue Links



              • Assignee:
                a10040 Kristian Amlie
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created:

                  Summary Panel