Testing

• Business -Business user define the problem only (& not venture into suggesting any solution)
• Development - Developers suggest ways to fix the problem
• Testing - Tester question the solution by bring up as many as many What-If

Keep Unit smaller

• Reduced debugging effort, smaller units aids in tracking down errors.
• Small test cases are easier to read and to understand.
• Developer writing tests may share blind spots with the code
• High number of passing unit tests may bring a false sense of security.
• Tests become part of the maintenance overhead of a project.
• Fragile test cases block the release.
• Generated code may give wront coverage report.
• Change in design break test case.
• Must add estimation of test case when estimating story

Limitation

• Test only small unit not the BDD
• DB & N/W Simulation
• Management may feel that time spent writing tests is wasted

---

Test-driven development TDD

Software-development methodology which essentially states that for each unit of software, a software developer must:

• define a test set for the unit first;
• make the tests fail;
• then implement the unit;
• finally verify that the implementation of the unit makes the tests succeed.

Advantage

• encourages simple designs and inspires confidence

---

Acceptance test–driven development(ATDD)

• Acceptance Test created when the requirements are analyzed and prior to coding usually in Xray

• Test defined in plain language with steps for Developer, QA & business

    Given Book that has not been checked out
    And User who is registered on the system
    When User checks out a book
    Then Book is marked as checked out
  

• Developer-tester-business customer collaboration while TDD is only for devs

• Written even before coding so that Dev can check if all requirement are fullfilled

---

Behavior-driven development BDD

Specifies that tests of any unit of software should be specified in terms of the desired behavior of the unit

• focuses on tests which describe behavior, rather than tests which test a unit of implementation in TDD

    private Game game;
    private StringRenderer renderer;
  
    @Given("a $width by $height game")
    public void theGameIsRunning(int width, int height) {
        game = new Game(width, height);
        renderer = new StringRenderer();
        game.setObserver(renderer);
    }
        
    @When("I toggle the cell at ($column, $row)")
    public void iToggleTheCellAt(int column, int row) {
        game.toggleCellAt(column, row);
    }
  
    @Then("the grid should look like $grid")
    public void theGridShouldLookLike(String grid) {
        assertThat(renderer.asString(), equalTo(grid));
    }
  

BDD Test case

    Given a 5 by 5 game
    When I toggle the cell at (3, 2)
    Then the grid should look like

---

Continuous test-driven development(CTDD)

• Extends test-driven development (TDD) by automatic test execution in the background.
• With each push of code CI/CD run tests