Skip to main content

Test Driven Development - TDD

Table of Contents​

  1. test the production code that's closest to the database

  2. Unit Testing

  3. Refactoring

  4. Inside Out Test First - Test Driven Development

  5. Outside In Behaviour First - Behaviour Driven Development

TDD Iteration

test the production code that's closest to the database​

  • application logic
  • database triggers
  • security rules
  • referential integrity

why test

Unit Testing​

  • Philosophy of Developer Unit Testing
  • Anatomy of Unit Testing Framework
  • Automated Tests
  • Overview of xUnit
  • Levels of Testing

Common Myths

Refactoring​

  • Purpose of Refactoring
  • Refactoring Patterns
  • Using Automated Refactoring

common opinions

Inside Out Test First - Test Driven Development​

  • Introduction to TDD
  • Test First Vs Test Last
  • TDD Rhythm: Red, Green, Refactor
  • Crucial Design Principles
  • Driving Design using TDD
  • Different Styles of TDD

Outside In Behaviour First - Behaviour Driven Development​

  • Driving Implementation and Design from Scenarios
  • Creating an Application from Scratch using Scenarios
  • Crafting acceptance criteria for user stories
  • Writing executable examples for each criteria
  • Documenting Scenarios with Gherkin
  • Demo of BDD frameworks (Cucumber, FitNesse, SpecFlow, Jasmine)
  • Automation Hazards
  • Safe Automation Practices

software QA

Beyond Basics​

  • Test Doubles/Fakes - Stubs, Mocks, Spy, Simulators...
  • TDD in Legacy Code
  • Breaking Dependencies in Legacy Code
  • Patterns for writing effective tests

Software Testing​

Software Quality Assurance (SQA) - An organisational quality guide:

  • Process that ensures that developed software meets and complies with defined or standard quality specifications.
  • Common Standards, regulations, and procedures to confirm work products during SDLC
  • SQA is an ongoing process within the software development lifecycle (SDLC) that routinely checks the developed software to ensure it meets desired quality measures.
  • SQA helps ensure the development of high-quality software.
  • Organisational knowledge base of best practices
  • Off-the-shelf software tools can be used
  • Preventive activities

Software Quality Plan (SQP):

  • It is a project level quality plan
  • Project commitment to follow applicable set of standards, regulations, procedures and tools during SDLC
  • Contains quality goals to be achieved
  • SQP may contain new procedures for the project which are not defined in organisation SQA guide
  • SQP may contain new tools being used in the project for SQA

Any deviation of an SQP from SQA should be justified by the project manager and be confirmed by the organisation management.

Software Quality Control (SQC):

  • Set of activities for ensuring quality in software products

  • Corrective activities

  • Quality Control (QC) can be considered as a subset of Quality Assurance (QA)

Examples:

Reviews​

  • Requirement Review
  • Design Review
  • Code Review
  • Deployment Plan Review
  • Test Plan Review
  • Test Cases Review

Types of Test Suites​

  • System Testing
  • Performance tests
  • Load tests
  • UAT (user acceptance tests)

Types of Tests

Unit Testing VS End-to-End​

  • unit is small isolated
  • e2e is comprehensive

Software Metrics​

Code Coverage img

  1. bugs per line of code
  2. code coverage
  3. cyclomatic complexity
  4. lines of code
  5. program size

Types of Tests​

  • Unit testing works by isolating small "units" of code so that it can be tested from every angle
    1. Best for testing services, classes and objects
    2. Sandboxed & Isolated testing
    3. Mocking & Stubbing required
  • Load Testing

img

  • e2e testing

the testing pyramid​

  • 80% of the tests should be unit tests, 15 % is integration tests and 5 % is UI tests. These percentages might vary depending on who you ask but the ratio should be around the same.

testing pyramid

img

Assertion​

  • Assert, Expect, Should Assert >> TDD

Expect, Should >> BDD

Mocking​

  • process used in unit testing when the unit being tested has external dependencies
  • dependencies are replaced by closely controlled replacements objects that simulate the behavior of the real ones

Spies​

  • fake functions that records how it is used (arguments, return value, etc)

Stubs​

  • fake function with predefined behavior
  • replaces a class with a small substitute that implements the same interface
  • To use stubs, you have to design your application so that each component depends only on interfaces, and not on other components

Shim​

  • modifies the compiled code of your application at run time so that instead of making a specified method call, it runs the shim code that your test provides. Shims can be used to replace calls to assemblies that you cannot modify, such .NET assemblies

Stub vs Shim​

  • stub types cannot be used for static methods, non-virtual methods, sealed virtual methods, methods in sealed types

  • Shims can replace calls to private methods if all the types on the method signature are visible. Stubs can only replace visible methods

  • Both stubs and shims can be used with internal types that are made accessible by using the assembly attribute InternalsVisibleToAttribute

Mocks​

  • fake function (spy and stub) where you define expectations in advance and assert

Prototyping​

UI Prototyping​

  • creating a scaffold to visually represent an application

Data Prototyping​

  • Mimic data passing back and forth from the server
  • quickly generate randomized data that mimics

Testing / Quality Assurance​

Bug Bash In software development, a bug bash is a procedure where all the developers, testers, program managers, usability researchers, designers, documentation folks, and even sometimes marketing people, put aside their regular day-to-day duties and "pound on the product"—that is, each exercises the product in every way they can think of. Because each person will use the product in slightly different (or very different) ways, and the product is getting a great deal of use in a short amount of time, this approach may reveal bugs relatively quickly.

Regression Testing​

https://github.com/mojoaxel/awesome-regression-testing

Mobile Testing​