Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.



Test-Driven Development

Bruno Chaina

on 1 June 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of TDD

Test-Driven Development
TDD as a Design Methodology
TDD as a Development Practice

Testing components in isolation
Inventory Sample
Code that follows SOLID practices
High degree of fidelity between code and business requirements
Built - in regression testing
It puts a stop to recurring bugs
Open, extensible and flexible architecture
Communication encouragement with the business

It helps keeping dead code out of the system
Creation of simpler, more focused libraries and APIs

Let the Tests drive the code you develop
Traditional workflow
Set of requirements
Working code
Set of requirements
Working code
Automated Tests
Manual Testing
Set of requirements
Working code
Manual Testing
Automated Testing
Manual Testing
Comfort zone
Quickly forgotten by developers
Unit tests become executable representations of specifications
Red, Green, Refactor
Red Phase
Test don't compile

Test compiles but fails
Green Phase
Write just enough code to make your new test pass while not causing any of the other tests to fail
Improve your code for maintainability, readability and overall code quality
Decoupling components with DI
Mocking with Moq

"A user should be able to add a new type of item to the application"
Simple, isolated, testable features
An item type entity and a persistence layer that can store the item entity in the data store

An item type domain service that can provide a list of item types in the data store

A user interface to enable business users to list existing item types and create new ones
Breaking the User Story
Top-down &
Bottom-up approaches
Naming the Tests
BDD naming style:

Business-user-friendly, meaningful and descriptive names

Class, method, and variable names mirror plain English as much as possible

Avoid using technical terms
Base test class name
Set of conditions
Nontechnical business users involvement
Test class name
Unit test name
BDD framework for .NET

Allows developers to create specifications (business rules written in plain English) and link them to executable test code
Setting up the starting conditions and environment
Executing the code under test
Evaluating the result
Method that executes the code under test
Provides a place to create the context under which your test will run
Triangulation of tests
Integration Testing
Integration tests cover all the application code between the method that the integration test was written for, all
the way to the lowest level of the system, usually the data store
The goal is not to test the individual units of code

The goal is to test the seams between the individual pieces of code

Isolation no longer applies
Interaction with external resources:

Read and write data to a database
Calls to a web service
Interaction with files or folders on the hard drive
End-to-End Integration Tests
They verify the complete integration of the application across all layers

They cover the entire system from as close as possible to the front end or user interface all the way through to the back-end data store, web service, or any other
external dependencies
Working with ASP.NET MVC
Full transcript