Showing posts with label TDD. Show all posts
Showing posts with label TDD. Show all posts

Wednesday, May 08, 2024

TDD @ IAG

  • Java-based test automation framework.
  • For each new feature expected to write an automation piece of code to validate the functionality. 
  • Expected to carry out TDD. Write a failed test case, and then write the TC to check functionality.
  • Not the same example as below, but this sort of gives an idea of what I did there.
  1. Add test [You don't write test for the code you are writing, rather you write the test code for the functionatliy you want to achieve] for the new functionality to be implemented. The tests serves as an [executable] specification. 
  2. That is you write one test, then implement enough code to pass that test, then refactor the existing code and test(s) if necessary, and then maybe commit or integrate before you get too much divergence from the main branch.
  3. Run the tests and confirm that the newly added tests fail.
  4. Implement the new functionality.
  5. Run all tests to confirm that they all pass.
  6. Optional: refactor the code to tidy things up now you know more.

// FactorialTest.java

import static org.junit.Assert.assertEquals;
import org.junit.Test;

public class FactorialTest {

    @Test
    public void testFactorial() {
        // Test case for factorial of 5
        assertEquals(120, Factorial.factorial(5));
    }
}

// Factorial.java

public class Factorial {

    public static int factorial(int n) {
        if (n < 0)
            throw new IllegalArgumentException("Factorial is not defined for negative numbers");
        else if (n == 0)
            return 1; // Base case: 0! = 1
        else
            return n * factorial(n - 1); // Recursive call for n!
    }
}

> assertEquals tests that factorial of 5 is equal to 120. It will fail when Factorial.java is not written. 

Monday, January 21, 2019

TDD vs. Create Test Case After Code

Test Case After Code
Test Case Before Code (TDD)
-         Focus is on artefacts
-         Writing tests after the code is a combination of recall of what has been coded and re-reading.
-         Relies much more on the discipline of the coder.
-         As a coder you may end up writing more code than is necessary when doing a test case after code
-         Requires coder to have a clue about where they are heading with the code.
-         It is the beginning of a detailed code design
-         We use the tests to literally drive function into the code, so that the fit between the test and code is much higher.
-         By writing a test before we are challenging ourselves to pass it.
-         TDD creates a narrowed focus, a narrow bandwidth to solve the issue on hand thereby ensuring optimized solution.

By writing test first, we force ourselves to design the program to be both testable as well as callable. This leads the class to be decoupled from its surroundings.

Diagram courtesy: Cohn

  • TDD takes about 15% longer than not doing TDD. But there is evidence that TDD leads to fewer defects. Bugs go down by 24% to 38%.
  • TDD may initially take a longer time, but will benefit the team in terms of reduced defects, reduced bug fixing and maintenance time.



If we already have automation, what's the need for Agents?

“Automation” and “agent” sound similar — but they solve very different classes of problems. Automation = Fixed Instruction → Fixed Outcome ...