{"id":96,"date":"2019-07-08T14:41:39","date_gmt":"2019-07-08T14:41:39","guid":{"rendered":"https:\/\/www.bddtesting.com\/?page_id=96"},"modified":"2019-07-08T14:41:39","modified_gmt":"2019-07-08T14:41:39","slug":"tdd-vs-bdd-what-do-they-mean-for-testers","status":"publish","type":"page","link":"https:\/\/www.bddtesting.com\/tdd-vs-bdd-what-do-they-mean-for-testers\/","title":{"rendered":"TDD vs BDD: What do they mean for Testers?"},"content":{"rendered":"\n

In recent years, we have encountered more and more Testers wishing to become involved in Unit Testing, learning techniques such as\u00a0TDD (Test Driven Development)<\/strong>\u00a0and\u00a0BDD (Behaviour Driven Development), and utilizing<\/strong> tools such as Selenium and Cucumber.<\/p>\n\n\n\n

“We need to learn Ruby and Cucumber”<\/h4>\n\n\n\n

Enthusiasm aside, many testers I have spoken with are responding to industry buzzwords and aren\u2019t familiar enough with these tools and techniques to understand where they, as testers, fit in.<\/p>\n\n\n\n

So while there may be an increasing requirement for technical testing capability, I would like to use this article to dispel the myth that all testers must be technical, share my opinions and provide a high level overview, starting with an explanation of some of these terms\u2026<\/p>\n\n\n\n

\"\"\/<\/figure>\n\n\n\n
Unit Testing and TDD<\/h5>\n\n\n\n

Unit Testing <\/strong>is a method by which very granular units of code are tested in isolation from their dependencies (such as integrated applications, databases and file systems) to determine that they are fit for purpose. Although I have heard reference to manual unit testing (?), in practice, good Unit Tests are automated with a small fragment of code used to assert an expected outcome.<\/p>\n\n\n\n

Test Driven Development (TDD)<\/strong> is the practice of writing a small automated Unit Test which initially fails, then writing the simplest and smallest amount of application code required to pass the test before refactoring and improving the quality of the code.<\/p>\n\n\n\n

With tests being written before the application code, TDD (also sometimes referred to as test-first development) really drives the quality of the product by keeping the software development team focused on writing simple, testable code.<\/p>\n\n\n\n

Since Unit Tests focus on the internals of the software, and are themselves written in code, they can be difficult to understand by stakeholders outside the development team. As such, there is often unease about the level of code coverage or the quality of the Unit Testing performed before System and Integration Testing can begin.<\/p>\n\n\n\n

Due to the required knowledge of the underlying architecture and implementation, and the quick iteration between test and application code, these responsibilities don\u2019t belong to testers, but to the application programmers (I\u2019m purposely avoiding the term Developer to avoid the ambiguity of Scrum teams, where all team members are labelled Developers).<\/p>\n\n\n\n

BDD<\/h5>\n\n\n\n

Behaviour Driven Development (BDD)<\/strong> is based upon Test Driven Development, but where TDD focuses on the inner workings of the software and the accuracy of the code (Unit Tests), BDD focuses on the requirements and the business value of the software (Acceptance Tests).<\/p>\n\n\n\n

Acceptance Tests are often modelled around User Stories (\u201cAs a [role] I want [feature] so that [benefit]\u201d) and Acceptance Criteria. Being written in natural language makes Acceptance Tests more easily understood by stakeholders outside of the software development team, such as BAs, Testers and Project Managers.<\/p>\n\n\n\n