Answers: <p>This is my opinion: Coverage says nothing about correctness, so if you are writing unit tests for coverage, you are doing it wrong. Unit tests shall originate in requirements, the resulting coverage is a measure for completeness of your test suite and your code quality. If the coverage is low, chances are that</p>
  
  <ul>
  <li>your unit tests don't cover all requirements.</li>
  <li>there is dead code.</li>
  </ul>
  
Answers: CC BY-SA 4.0
Answers: 2018-06-06T21:54:49.003Z
Answers: 2018-06-06T21:54:49.003Z
Answers: simonz
Answers: <p>The way I would approach this would be to have a second part of the junit test that reads the generated zip file and then verifies it is correct. You are right that if you are only ensuring you can generate the file, but the file is incorrect, the unit test is incomplete.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-06-06T15:19:07.393Z
Answers: 2018-06-06T15:19:07.393Z
Answers: mike
Body: <p>We are working on a big Java project where we use JUnit tests. Our Jenkins helps us to monitor the code coverage and shows us the progress we make with this.</p>
  
  <p>But there seems to be something lacking here. In our case, one of the apps results in a zip file with data files generated based on different source files.</p>
  
  <p>All code to generate these data files is covered, but that doesn't tell us if the content of the generated files itself is OK. Is this just a matter of generating additional JUnit tests and rely on the knowledge of the team to know what needs to be tested? Or can this be controlled and monitored in some way?</p>
  
Tags: <jenkins><testing><builds><code-coverage>
Title: Code coverage versus functional coverage
UserDisplayName: Frank
ThreadText: # Code coverage versus functional coverage
  
  (Asked by: username_0 on 2018-06-06)
  
  We are working on a big Java project where we use JUnit tests. Our Jenkins helps us to monitor the code coverage and shows us the progress we make with this.
  
  But there seems to be something lacking here. In our case, one of the apps results in a zip file with data files generated based on different source files.
  
  All code to generate these data files is covered, but that doesn't tell us if the content of the generated files itself is OK. Is this just a matter of generating additional JUnit tests and rely on the knowledge of the team to know what needs to be tested? Or can this be controlled and monitored in some way?
  
  **Tags:** jenkins, testing, builds, code-coverage
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2018-06-06. Score: 1
  
  This is my opinion: Coverage says nothing about correctness, so if you are writing unit tests for coverage, you are doing it wrong. Unit tests shall originate in requirements, the resulting coverage is a measure for completeness of your test suite and your code quality. If the coverage is low, chances are that
  
  * your unit tests don't cover all requirements.
  * there is dead code.
  
  
  ---
  
  ### Answer by username_2 on 2018-06-06. Score: 1
  
  The way I would approach this would be to have a second part of the junit test that reads the generated zip file and then verifies it is correct. You are right that if you are only ensuring you can generate the file, but the file is incorrect, the unit test is incomplete.
  
  
  ---
  
  