Setting up for TTD in Visual Studio 2012Project | Manage NuGet Packages

Select the online tabSearch for NunitSelect the Nunit package

Follow these instructions to download and install the Nunit test adapter: http://nunit.org/index.php?p=vsTestAdapter&r=2.6

Setting up for TDD in EclipseSee steps 4 and 5 in this tutorial:http://mobile.tutsplus.com/tutorials/android

/android-sdk-junit-testing/

Reducing Dependency

Class Interdependency When one class depends on another

there are undesirable consequencesIt is more difficult to reuse the dependent

classIt is more difficult to maintain the dependent

classIt is more difficult to test the dependent class

Class DependencyClass A is said to be dependent on class B

when class B is required for class A’s specification or implementation.

Example:class Car { : private: Engine theEngine; };

The Car class depends on the Engine class.

UML Indication of dependencyThe Car class depends on the Engine class

Car Engine

We will try to remove dependencies when practicalWe can remove a dependency on a class by

changing it to a dependency on an interface.

Car can now use any propulsion system that implements the interface “Propulsion System”

Car

Engine

Propulsion System<<interface>>

Car class is much more extensible now.

Car

Electric Engine

Propulsion System<<interface>>

Internal Combustion Engine Flux Capcitance Engine

It is also easier to test!We can write fakes classes that implement Propulsion System for unit tests.

Car

Electric Engine

Propulsion System<<interface>>

Internal Combustion Engine Flux Capcitance Engine FakePropulsionForUnitTests

We broke an interclass dependency using an interfaceBenefits

Car can now have any engine that implements the Propulsion System interfaceAs new engines are developed, we can use them in

Car – provided that the new engines implement the Propulsion System Interface.

This makes Car easier to test, because we can make fake classes that implement Propulsion System.

Dependency Inversion PrincipleDepend upon abstractions: Do not depend

upon concrete classes.Code to interfaces – not class definitions.High-level components should not depend on

low-level componentsBoth high-level and low-level classes should depend

on abstractions.Car

Engine

Propulsion System<<interface>>

Guidelines for reducing Dependencies(Head-first Design Patterns)Beware of variables that hold references to

concrete classesBeware of classes that derive from concrete

classesBeware of classes that override an

implemented member function in a base classesBecause the subclass is relying on a concrete

class, not an abstraction.

Interfaces in C++

// In C++ we can implement interfaces as abstract base classes // in which all member functions are public pure virtual.class PropulsionSystem{ public: // Request that the engine produce a certain amount of energy. virtual void requestBTU(float BTUs) = 0;

// See how much energy the engine is currently producing virtual float getBTU() = 0; };

Instantiating the Propulsion InterfaceMethod 1: Constructor Instantiationclass Car{ private: PropulsionSystem* propulsionSystem_;};

Car::Car(PropulsionSystem propulsionSystem) : propulsionSystem_(propulsionSystem) {}

Car::~Car(){ delete propulsionSystem_;}

Using Constructor InstantiationCar myCar(new InternalCombustionEngine());Car myElectricCar(new ElectricEngine());Car myTestCar(new FakeEngine());

/* The use of the interface provides flexibility; however, as soon as we say new we must refer to a concrete class and thus generate a dependency */

Instantiating the Propulsion InterfaceMethod 2: getter/setter Instantiationclass Car{ public: setPropulsionSystem(PropulsionSystem* newSystem); private: PropulsionSystem* propulsionSystem_;};// UsageCar myCar;myCar.setProulsionSystem(new ElectronicEngine());

A Simple Factory ClassesSimple Factory class act like virtual

constructors. You send the simple factory some information about your situation, and it returns the appropriate class.

class SimplePropulsionFactory{ public:

static PropulsionSystem* createPropulsion(const string& reqs);};

Simple Factory createPropulsionPropulsionSystem* SimplePropulsionFactory::createPropulsion(const string& req){ PropulsionSystem* prop = 0; if(string == “green”) prop = new ElectricEngine(); if (string == “fast”) prop = new InternalCombustionEngine(); if (string == “test”) prop = new FakeEngine(); return prop;}

Instantiating the Propulsion class Method 3: Using a Simple Factory // Create a propulsion system using the factory – pass the // factory to the Car constructor.PropulsionSystem prop = SimpleFactory::createPropulsion(“green”);Car myCar(prop);

Method 4: Allow the subclasses to decide: Factory Method Patternclass Car{ virtual void createPropulsion() = 0;};

class GreenCar : public Car{ void createPropulsion() { propulsionSystem_ = new ElectricEngine(); }}

Method 5: The Abstract Factory PatternThe Abstract Factory Pattern provides an

interface for creating families of related or dependent object without specifying their concrete classes. [Head First Design Patterns]There may be a number of things that vary from

Car to CarPropulsion SystemsExhaust SystemsSaftey Systems

Create an interface for an abstract factory that produces each of the items that vary across Cars

CarCompnentFactory is an Example of the Abstract Factory Patternclass CarComponentFactory

{

public:

PropulsionSystem* createPropulsion() = 0;

ExhaustSystem* createExaustSystem() = 0;

SafteySystem* createSaftySystem() = 0;

};

class CaliforniaComponentFactory{ // overrides abstract methods with concrete implementations }class EuropeanUnionComponentFactory{ // overrides abstract methods with concrete implementations}