└── README.md


/README.md:
--------------------------------------------------------------------------------
 1 | # Frequently needed arguments about software quality
 2 | 
 3 | ## What?
 4 | 
 5 | A collection of frequently needed arguments about well established (empirically validated) practices related to software quality.
 6 | 
 7 | ## Why?
 8 | 
 9 | As a software engineer that cares about quality and that frequently gets involved with new projects in companies or in the open source environment, I usually see the same discussions about a specific topic happen every now and then. 
10 | 
11 | The problem is that I don't always remember the arguments that led me to a given conclusion, so I'm creating this repository to aggregate these arguments and maybe even change my conclusions by exposing them to different opinions and having discussions around them.
12 | 
13 | ## Tests with conditional execution paths should be avoided
14 | 
15 | Tests with conditional execution paths are intrinsically non-deterministic, they mix responsibilities of what could possibly be multiple test cases in one, turning the outcome of the test difficult to read and reason about. While a deterministic test has two possible results (it has either passed or failed) a test with conditional paths can have multiple reasons for either passing or failure states. 
16 | 
17 | Read more:
18 | - [Nondeterministic algorithm](https://en.wikipedia.org/wiki/Nondeterministic_algorithm)
19 | - [Eradicating non-determinism in tests](https://martinfowler.com/articles/nonDeterminism.html)
20 | 
21 | ## BDD is not about testing, it is not a testing approach (same applies to TDD)
22 | 
23 | BDD is a design activity meant to leverage communication within the team while guiding the development with an outside-in approach. The fact that by aplying BDD you end up with automated tests is just a side effect but not the main goal.
24 | 
25 | Read more:
26 | - [BDD is not about testing](https://speakerdeck.com/tastapod/bdd-is-not-about-testing)
27 | - [TDD is not about testing](http://java.sys-con.com/node/37795)
28 | - [TDD is about design not testing](http://www.drdobbs.com/tdd-is-about-design-not-testing/229218691)
29 | 
30 | ## TDD vs Unit testing
31 | 
32 | TDD and Unit testing are [orthogonal](https://en.wikipedia.org/wiki/Orthogonality_(programming)) concepts.
33 | 
34 | Although it is common to use TDD to drive the design of small pieces of behavior, TDD is not only for this level of granularity. 
35 | 
36 | One can apply TDD at any level of granularity, for instance:
37 |  - in the acceptance level 
38 |  - in the integration level or 
39 |  - in the unit level
40 |  
41 | Unit testing is a somewhat vague concept that usually refers to testing the smallest piece of behavior that you care about. You can write unit tests before you write the code for it to pass, while you write the code or after. TDD in the other hand is a design activity that uses tests as specifications to drive the solution in an outside-in fashion. It's the developer's responsibility to define the level of granularity that they want to drive out with the test.
42 | 


--------------------------------------------------------------------------------