Answers: <p>I support J.Doe's suggestion for separate Docker files for each of the build and test stage. Such approach also allows you to:</p>
  
  <ul>
  <li>re-run the test stage for whatever reason (known intermittent failures, for example) without re-doing the build stage</li>
  <li>run multiple <em>different</em> test stages in parallel using the same build - for example instead of running a single long test stage made up of serialized tests, for a potentially significant overall pipeline speeding up.</li>
  </ul>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-28T14:46:56.270Z
Answers: 2017-06-28T14:46:56.270Z
Answers: Dan Cornilescu
Answers: <p>If you run everything in the same container...</p>
  
  <p><strong>PRO:</strong> you have solved the CasC challenge for configuring the testing environment inline as well</p>
  
  <p><strong>CON:</strong> you miss the blackbox tesing part, imagine your container wouldn't accepts connections from outside. Ouch!</p>
  
  <p>Possible solution: I'd go therefore for a multi-stage Docker-based declarative pipeline: one Docker environment for each stage where artefacts cascade along it.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-06-28T12:58:12.367Z
Answers: 2017-06-28T14:36:22.060Z
Answers: 2017-06-28T14:36:22.060Z
Answers: Ta Mu
Body: <p>Our dockerfile creates the application environment (e.g. env variables, install libraries with apt-get etc.). It also pulls and copies the python application code from its git repo.</p>
  
  <p>However, we are debating whether the application tests (some unit, some integration) should be put within a docker <code>RUN</code> command (e.g. <code>RUN /bin/bash -c "source activate cool_env; pytest"</code>) or after the build using the CI stack (e.g. Jenkins, Openshift) to execute the tests on the built container.</p>
  
  <p>What are the pros and cons of each?</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-09-07T05:05:28.573Z
Comments: there is also a new feature, multi-stage builds which allows you to have both build and test in the same Dockerfile.
Comments: Ta Mu
Tags: <jenkins><docker><testing><python>
Title: What are the pros and cons of running application testing during vs. after a docker build?
UserDisplayName: cammil
ThreadText: # What are the pros and cons of running application testing during vs. after a docker build?
  
  (Asked by: username_0 on 2017-06-28)
  
  Our dockerfile creates the application environment (e.g. env variables, install libraries with apt-get etc.). It also pulls and copies the python application code from its git repo.
  
  However, we are debating whether the application tests (some unit, some integration) should be put within a docker `RUN` command (e.g. `RUN /bin/bash -c "source activate cool_env; pytest"`) or after the build using the CI stack (e.g. Jenkins, Openshift) to execute the tests on the built container.
  
  What are the pros and cons of each?
  
  **Tags:** jenkins, docker, testing, python
  
  > **Comments:**
  > **username_1**: there is also a new feature, multi-stage builds which allows you to have both build and test in the same Dockerfile.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_2 on 2017-06-28. Score: 3
  
  I support J.Doe's suggestion for separate Docker files for each of the build and test stage. Such approach also allows you to:
  
  * re-run the test stage for whatever reason (known intermittent failures, for example) without re-doing the build stage
  * run multiple *different* test stages in parallel using the same build - for example instead of running a single long test stage made up of serialized tests, for a potentially significant overall pipeline speeding up.
  
  
  ---
  
  ### Answer by username_1 on 2017-06-28. Score: 2
  
  If you run everything in the same container...
  
  **PRO:** you have solved the CasC challenge for configuring the testing environment inline as well
  
  **CON:** you miss the blackbox tesing part, imagine your container wouldn't accepts connections from outside. Ouch!
  
  Possible solution: I'd go therefore for a multi-stage Docker-based declarative pipeline: one Docker environment for each stage where artefacts cascade along it.
  
  
  ---
  
  