The Three Laws of TDD

• TDD ( Test-driven development )

  • First Law You may not write production code until you have written a failing unit test.

    • Ensure that every feature or functionality is defined and tested upfront
    • Test > Code use test to find the code purpose goal

  • Second Law You may not write more of a unit test than is sufficient to fail, and not compiling is failing.

    • Focus on small, incremental steps to implement functionality. This keeps the code simple and test-driven.
    • Small Test

  • Third Law You may not write more production code than is sufficient to pass the currently failing test.

    • Avoid over-engineering. Write only what’s necessary to make the test pass and no more.
    • Efficient logic of code

    The sheer bulk of those tests, which can rival the size of the production code itself, can present a daunting management problem.

Keep Tests Clean

• Having dirty tests is equivalent to having no tests.
• Without a test suite they could not ensure that changes to one part of their system did not break other parts of their system.
• Test code is just as important as production code

Tests Enable the -ilities

• With tests that fear virtually disappears. The higher your test coverage, the less your fear
• you can improve that architecture and design without fear!

Clean Tests

• Three things. Readability, readability, and readability.

  • What makes tests readable? The same thing that makes all code readable: clarity, simplicity, and density of expression.

  SerializedPageResponderTest.java(refactored)
  
  public void testGetPageHierarchyAsXml() throws Exception {
      makePages("PageOne", "PageOne.ChildOne", "PageTwo");
      submitRequest("root", "type:pages");
      assertResponseIsXML();
      assertResponseContains(
          "<name>PageOne</name>", "<name>PageTwo</name>", "<name>ChildOne</name>"
      );
  }
  public void testSymbolicLinksAreNotInXmlPageHierarchy() throws Exception {
  		WikiPage page = makePage("PageOne");
      makePages("PageOne.ChildOne", "PageTwo");
      addLinkTo(page, "PageTwo", "SymPage");
      
      submitRequest("root", "type:pages");
      assertResponseIsXML();
      assertResponseContains(
          "<name>PageOne</name>", "<name>PageTwo</name>", "<name>ChildOne</name>"
      );
      assertResponseDoesNotContain("SymPage");
  }
   
  public void testGetDataAsXml() throws Exception {
      makePageWithContent("TestPageOne", "test page");
      submitRequest("TestPageOne", "type:data");
      assertResponseIsXML();
      assertResponseContains("test page", "<Test");
  }
  

  BUILD-OPERATE-CHECK

Domain-Specific Testing Language

• Build up a set of functions and utilities that make use of those APIs and that make the tests more convenient to write and easier to read.
• This testing API is not designed up front; rather it evolves from the continued refactoring.

A Dual Standard

• It must still be simple, succinct, and expressive, but it need not be as efficient as production code. After all, it runs in a test environment, not a production environment,

  @Test
   public void turnOnLoTempAlarmAtThreashold() throws Exception {
  	 hw.setTemp(WAY_TOO_COLD);
  	 controller.tic();
  	 assertTrue(hw.heaterState());
  	 assertTrue(hw.blowerState());
  	 assertFalse(hw.coolerState());
  	 assertFalse(hw.hiTempAlarm());
  	 assertTrue(hw.loTempAlarm());
   }
  

  Improve reading (But with not efficient code)

  @Test
   public void turnOnLoTempAlarmAtThreshold() throws Exception {
  	 wayTooCold();
  	 assertEquals("HBchL", hw.getState());
   }
   
   public String getState() {
  	 String state = "";
  	 state += heater ? "H" : "h";
  	 state += blower ? "B" : "b";
  	 state += cooler ? "C" : "c";
  	 state += hiTempAlarm ? "H" : "h";
  	 state += loTempAlarm ? "L" : "l";
  	 return state;
   }
  

  That is the nature of the dual standard. There are things that you might never do in a production environment that are perfectly fine in a test environment. Usually they involve issues of memory or CPU efficiency. But they never involve issues of cleanliness.

One Assert per Test

• Single assert rule is a good guideline, I think the best thing we can say is that the number of asserts in a test ought to be minimized.
  • If multiple assertions are part of validating a single concept, splitting them may seem artificial.
    • ⇒ But I think this mean the test may violate the Single responsibility principle…

Single Concept per Test

• Three concept in one test

  public void testAddMonths() {
  	 SerialDate d1 = SerialDate.createInstance(31, 5, 2004);
  	 
  	 SerialDate d2 = SerialDate.addMonths(1, d1);
  	 assertEquals(30, d2.getDayOfMonth());
  	 assertEquals(6, d2.getMonth());
  	 assertEquals(2004, d2.getYYYY());
  	 
  	 SerialDate d3 = SerialDate.addMonths(2, d1);
  	 assertEquals(31, d3.getDayOfMonth());
  	 assertEquals(7, d3.getMonth());
  	 assertEquals(2004, d3.getYYYY());
  	 
  	 SerialDate d4 = SerialDate.addMonths(1, SerialDate.addMonths(1, d1));
  	 assertEquals(30, d4.getDayOfMonth());
  	 assertEquals(7, d4.getMonth());
  	 assertEquals(2004, d4.getYYYY());
  	 
   }