Test Driven Development(TDD)
Software Testing Methodologies
Intro
 Test Driven Development is a
software testing methodology where
developers write automated test
cases for new modules or features
before writing any code, that it
begins by writing a failing test for
the piece of functionality you are
going to implement, then you write
the simplest code possible to pass
that test. Once this is done, the
new code is refactored
Intro
 Test Driven Development is a
software testing methodology where
developers write automated test
cases for new modules or features
before writing any code, that it
begins by writing a failing test for
the piece of functionality you are
going to implement, then you write
the simplest code possible to pass
that test. Once this is done, the
new code is refactored
How It Works ?
1. Add a Test
 Use Cases / User Stories are used to understand the requirement clearly
2. Run all tests and see the new one fail
 Ensures test harness is working correctly
 Ensures that test does not mistakenly pass
3. Write some code
 Only code that is designed to pass the test
 No additional functionality should be included because it will be untested
4. Run the automated tests and see them succeed
 If tests pass, programmer can be confident code meets all tested requirements
5. Refactor code
 Cleanup the code
 Rerun tests to ensure cleanup did not break anything
Repeat
Test First vs. Test Last
TDD Benefits
 Instant Feedback
 Developer knows instantly if new code works and if it interferes with existing code
 Better Development Practices
 Encourages the programmers to decompose the problem into manageable, formalized
programming tasks
 Quality Assurance
 Having up-to-date tests in place ensures a certain level of quality
 TDD practices drive programmers to write code that is automatically testable
 Whenever a software defect is found, unit test cases are added to the test suite prior to
fixing the code
 Lower Rework Effort
 Eliminating defects early in the process usually avoids lengthy and tedious debugging
later in the project
 “Cost of Change” is that the longer a defect remains the more difficult and costly to
remove
TDD Limitations
 Difficult in Some Situations
 GUIs, Relational Databases, Web Service
 Requires mock objects
 Focus is on implementation and less on the logical structure
 Difficult to write test cases for hard-to-test code
 TDD blurs distinct phases of Software Development Life Cycle (SDLC)
 design, code and test
TDD Survey
Results of a survey conducted by 24 professional programmers
Types of Software Testing
 Functional testing types include:
 Integration testing
 Unit testing
 System testing
 Interface testing
 Beta/Acceptance testing
 Non-functional testing types include:
 Performance Testing
 Load testing
 Stress testing
 Security testing
 Compatibility testing
 Install testing
 Reliability testing
 Usability testing
What is Unit Testing?
 Unit testing is a software development process in which
the smallest testable parts of an application, called
units, are individually and independently tested.
 Is Independent of the surrounding environment,
excluding any external dependencies like any database
connection or any external requests in general. *Mocking
 Unit Testing Frameworks for JAVA:
 JUnit
 TestNG
 Mockito
What is Mocking ?
 Mock is a method/object that simulates the behavior of a real method/object in controlled ways.
Mock objects are used in unit testing. Often a method under a test calls other external services or
methods within it. These are called dependencies. Once mocked, the dependencies behave the
way we defined them
 Mocking is primarily used in unit testing. A Module under test may have dependencies on other
Modules/Dependencies. To isolate the behavior of the module you want to replace the other
dependencies by mocks that simulate the behavior of the real dependencies. This is useful if the
real dependencies are impractical to incorporate into the unit test. And that’s because that
any Unit Test should test functionality in isolation.
 For Example: you want to unit test a module that will dependent on data from a database
which is not yet built, so it will be easier and faster to use mocking in unit testing the module
instead of building a real database and filling it with fake data for the unit test.

Test driven development(tdd)

  • 1.
  • 2.
    Intro  Test DrivenDevelopment is a software testing methodology where developers write automated test cases for new modules or features before writing any code, that it begins by writing a failing test for the piece of functionality you are going to implement, then you write the simplest code possible to pass that test. Once this is done, the new code is refactored
  • 3.
    Intro  Test DrivenDevelopment is a software testing methodology where developers write automated test cases for new modules or features before writing any code, that it begins by writing a failing test for the piece of functionality you are going to implement, then you write the simplest code possible to pass that test. Once this is done, the new code is refactored
  • 4.
    How It Works? 1. Add a Test  Use Cases / User Stories are used to understand the requirement clearly 2. Run all tests and see the new one fail  Ensures test harness is working correctly  Ensures that test does not mistakenly pass 3. Write some code  Only code that is designed to pass the test  No additional functionality should be included because it will be untested 4. Run the automated tests and see them succeed  If tests pass, programmer can be confident code meets all tested requirements 5. Refactor code  Cleanup the code  Rerun tests to ensure cleanup did not break anything Repeat
  • 5.
    Test First vs.Test Last
  • 6.
    TDD Benefits  InstantFeedback  Developer knows instantly if new code works and if it interferes with existing code  Better Development Practices  Encourages the programmers to decompose the problem into manageable, formalized programming tasks  Quality Assurance  Having up-to-date tests in place ensures a certain level of quality  TDD practices drive programmers to write code that is automatically testable  Whenever a software defect is found, unit test cases are added to the test suite prior to fixing the code  Lower Rework Effort  Eliminating defects early in the process usually avoids lengthy and tedious debugging later in the project  “Cost of Change” is that the longer a defect remains the more difficult and costly to remove
  • 7.
    TDD Limitations  Difficultin Some Situations  GUIs, Relational Databases, Web Service  Requires mock objects  Focus is on implementation and less on the logical structure  Difficult to write test cases for hard-to-test code  TDD blurs distinct phases of Software Development Life Cycle (SDLC)  design, code and test
  • 8.
    TDD Survey Results ofa survey conducted by 24 professional programmers
  • 9.
    Types of SoftwareTesting  Functional testing types include:  Integration testing  Unit testing  System testing  Interface testing  Beta/Acceptance testing  Non-functional testing types include:  Performance Testing  Load testing  Stress testing  Security testing  Compatibility testing  Install testing  Reliability testing  Usability testing
  • 10.
    What is UnitTesting?  Unit testing is a software development process in which the smallest testable parts of an application, called units, are individually and independently tested.  Is Independent of the surrounding environment, excluding any external dependencies like any database connection or any external requests in general. *Mocking  Unit Testing Frameworks for JAVA:  JUnit  TestNG  Mockito
  • 11.
    What is Mocking?  Mock is a method/object that simulates the behavior of a real method/object in controlled ways. Mock objects are used in unit testing. Often a method under a test calls other external services or methods within it. These are called dependencies. Once mocked, the dependencies behave the way we defined them  Mocking is primarily used in unit testing. A Module under test may have dependencies on other Modules/Dependencies. To isolate the behavior of the module you want to replace the other dependencies by mocks that simulate the behavior of the real dependencies. This is useful if the real dependencies are impractical to incorporate into the unit test. And that’s because that any Unit Test should test functionality in isolation.  For Example: you want to unit test a module that will dependent on data from a database which is not yet built, so it will be easier and faster to use mocking in unit testing the module instead of building a real database and filling it with fake data for the unit test.

Editor's Notes

  • #5 Code Refactoring is Changing the internal structure of the code without changing it’s external behavior.