Answers: <p>TL;DR: See <strong>bold</strong> sentence below.</p>
  <hr />
  <p>I know the <em>separation of concerns (SoC) principle</em> mostly from a &quot;software code organisation&quot; point of view. I never explicitly encountered it for build job definitions up to now (which does not mean it is bad to follow it in this context too).</p>
  <p>From my point of view: <em>Principles</em> and <em>good</em> (or even <em>best</em>) <em>practices</em> exist for a reason. Following them can help you guide your project to success, because they seem to appear often in successful projects<sup>[citation needed]</sup>.</p>
  <p>This does not mean that every successful project follows all best practices. On the other hand, following them does not automatically make your project successful.<sup>[citation needed, too]</sup></p>
  <p>Please note that I don't know building Docker images with GitLab well enough to give you advice in this direction. Maybe GitLab provides some special mechanism directly for this use case?</p>
  <hr />
  <p>In your case:</p>
  <p>The main goals of SoC are to manage complexity, increase modularity and facilitate maintenance.</p>
  <p>I summarise the points you give in your question as <em>increase pipeline efficiency</em>.</p>
  <p>So the questions are:</p>
  <ul>
  <li>Does &quot;test during build&quot; increase the performance so much that it pays the additional maintenance costs?</li>
  <li>How complex are the building and testing logics for themselves? How easy is it to split them apart again if you put them together now?</li>
  <li>To put in the two additional principles &quot;<em>Premature Optimization</em>&quot; and &quot;<em>You Aren’t Gonna Need It</em>&quot;: Do you <em>really</em> need this efficiency now? On the other hand, do you <em>really</em> need the separation now?</li>
  <li>Maybe it is possible to do both, separate building and testing each in their own script files but call them both from one job?</li>
  </ul>
  <p><strong>If you cannot find strong arguments in favour of one or the other now, do as you like and be prepared to refactor later when your needs become clearer.</strong> Whatever you do, document your decision and the reasons for it together with the alternative as comments in your pipeline definition. Example:</p>
  <blockquote>
  <p>Build and test are done in a single job to avoid pushing/pulling the Docker image to/from registry to increase performance. If the complexity of build/test logic increases too much, split them in separate steps and check if performance is still acceptable.</p>
  </blockquote>
  <p>This way you and your colleagues in the future can better understand <em>why</em> it is the way it is currently and whether it makes sense to change it.</p>
  
Answers: CC BY-SA 4.0
Answers: 2021-12-31T12:44:40.517Z
Answers: 2021-12-31T12:44:40.517Z
Answers: siegi
Body: <ul>
  <li>We want to run unit tests against a built Docker image and not by installing the environment inside Gitlab CI runner</li>
  <li>We don't want to push the docker image to a registry and pull it back in a test job to run unit tests - it's slower.</li>
  </ul>
  <p>But it contradicts the separation of concerns principle - now our build job will also run unit tests.</p>
  <p>The question for the community: is it okay to sacrifice this principle in this case or there are better alternatives?</p>
  
Comments: CC BY-SA 4.0
Comments: 2021-12-28T03:04:32.480Z
Comments: It's perfectly fine for unit tests, assuming they run in a short amount of time. Where you would need to have a distinct environment would be called integration tests - those are different.
Comments: taleodor
Tags: <continuous-integration><gitlab>
Title: Is it a good practice to run unit tests inside build job in Gitlab CI?
UserDisplayName: Alexander Reshytko
ThreadText: # Is it a good practice to run unit tests inside build job in Gitlab CI?
  
  (Asked by: username_0 on 2021-12-27)
  
  * We want to run unit tests against a built Docker image and not by installing the environment inside Gitlab CI runner
  * We don't want to push the docker image to a registry and pull it back in a test job to run unit tests - it's slower.
  
  But it contradicts the separation of concerns principle - now our build job will also run unit tests.
  
  The question for the community: is it okay to sacrifice this principle in this case or there are better alternatives?
  
  **Tags:** continuous-integration, gitlab
  
  > **Comments:**
  > **username_1**: It's perfectly fine for unit tests, assuming they run in a short amount of time. Where you would need to have a distinct environment would be called integration tests - those are different.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2021-12-31. Score: 3 | Accepted answer
  
  TL;DR: See **bold** sentence below.
  
  ---
  
  I know the *separation of concerns (SoC) principle* mostly from a "software code organisation" point of view. I never explicitly encountered it for build job definitions up to now (which does not mean it is bad to follow it in this context too).
  
  From my point of view: *Principles* and *good* (or even *best*) *practices* exist for a reason. Following them can help you guide your project to success, because they seem to appear often in successful projects[citation needed].
  
  This does not mean that every successful project follows all best practices. On the other hand, following them does not automatically make your project successful.[citation needed, too]
  
  Please note that I don't know building Docker images with GitLab well enough to give you advice in this direction. Maybe GitLab provides some special mechanism directly for this use case?
  
  ---
  
  In your case:
  
  The main goals of SoC are to manage complexity, increase modularity and facilitate maintenance.
  
  I summarise the points you give in your question as *increase pipeline efficiency*.
  
  So the questions are:
  
  * Does "test during build" increase the performance so much that it pays the additional maintenance costs?
  * How complex are the building and testing logics for themselves? How easy is it to split them apart again if you put them together now?
  * To put in the two additional principles "*Premature Optimization*" and "*You Aren’t Gonna Need It*": Do you *really* need this efficiency now? On the other hand, do you *really* need the separation now?
  * Maybe it is possible to do both, separate building and testing each in their own script files but call them both from one job?
  
  **If you cannot find strong arguments in favour of one or the other now, do as you like and be prepared to refactor later when your needs become clearer.** Whatever you do, document your decision and the reasons for it together with the alternative as comments in your pipeline definition. Example:
  
  > Build and test are done in a single job to avoid pushing/pulling the Docker image to/from registry to increase performance. If the complexity of build/test logic increases too much, split them in separate steps and check if performance is still acceptable.
  
  This way you and your colleagues in the future can better understand *why* it is the way it is currently and whether it makes sense to change it.
  
  
  ---
  
  