using System;
using NUnit.Framework;
namespace TestableAppTests
{
/// <summary>
/// The code below runs some simple unit tests to test our Drawing object can have
/// objects added to it.
/// We create an IDrawing interface, this is an interface for the wrapper of the real
/// Bricscad drawing database, we could call it Database but we will keep things simple
/// and 'different' enough that we can't confuse our db with the cad one.
/// </summary>
[TestFixture]
public class UnitTest1
{
/// <summary>
/// Let's write the first test to see if we can add an object to the drawing.
/// </summary>
[Test]
public void AddObjectToDrawingReturnsLong() // we want a long returned, see below.
{
var drawing
= new MyDrawingHelper
(); // implements IDrawing interface.
// now test the AddObject method we are about to write, as we don't have
// a concrete class for objects yet we can see we need another interface
// for drawing objects. The implementation of the drawing object is not
// important yet, not for testing this MyDrawing class anyway.
//
// We need to either return some sort of result object or other device
// to tell us we have succeeded, an object id is good as we can store
// them in simple lists etc for retrieving them from the drawing object
// at a later time when needed (and follows typical cad return types as well).
var drawingObject
= new DrawingObjectHelper
(); long objectId = drawing.AddObject(drawingObject);
Assert.AreEqual(1234, objectId);
}
}
/// <summary>
/// Here is our IDrawing interface, the first thing I want to do is add things to it,
/// it's a good a place as any to start.
/// Ideally we would like to write the proper implementation details that work with
/// the drawing database proper but the goal here is to create the api for our Drawing class.
/// By creating tests first and only creating the ones we want we can defer the details until later
/// and we can continue to develop our application in isolation knowing we have 'somewhere'
/// to store our objects.
/// </summary>
public interface IDrawing
{
/// <summary>
/// Here is the method signature for our interface, already we can see we need another
/// class to represent the objects we want to add to the Drawing, we will create an interface
/// for this class as well so we can do our testing.
/// We are not interested in what or how the object works yet, that's not the purpose of these
/// particular tests, we just want to make sure we can add objects and catch any errors.
/// </summary>
/// <param name="drawingObject"></param>
/// <returns></returns>
long AddObject(IDrawingObject drawingObject);
}
/// <summary>
/// Our drawing implementation. This is basically a 'mock' and could just as easily been
/// created using the Moq library but to make things clearer for now we'll do it the hard
/// way by creating a helper class with dummy implementation. For simple objects this suffices
/// but you will soon see where using mocks will save a bit of time and code.
/// </summary>
public class MyDrawingHelper : IDrawing
{
public long AddObject(IDrawingObject drawingObject)
{
// hard code a know answer here, this is the work of the real
// database. It's easy to see we need to do some error handling from this
// which will be the next test.
long id = 1234;
return id;
}
}
/// <summary>
/// Our Drawing Object interface, we use this with all objects we ant to add
/// to the drawing.
/// </summary>
public interface IDrawingObject
{
// nothing to do here yet, will no doubt end up another set of tests for our real objects.
}
/// <summary>
/// The helper class for our drawing object to be passed in as an argument
/// Again, don't worry about this class, it's only a mock up of what we need later,
/// the point is our Drawing api will take any class that implements
/// the IDrawingObject interface.
/// </summary>
public class DrawingObjectHelper : IDrawingObject
{
}
}