CODEWITHSUNDEEP
tdddto
PcPulsar
PcPulsar

Reputation: 444

first time TDD help needed

Its (almost) my first time trying to create code by TDD principles. But i'm having troubles how to start.

In example: I want to mutate some information about a person.

To make it easy, a person has only these values: - FirstName - LastName - Email

What i need at the end: - A person DTO - A person entity (Nhibernate) - Functionality to store the dto values in the Database. At the end i need to return a succes or an error (possibly a boolean).

With the given information, how to start at all? It's a global question, but that's because i have no clue how to start. I've red many articles but somehow i get stuck already.

Edit: - I'm using MVC: MVC will give a DTO (filled from form fields) back.

So the MVC start call could be something like this: 

public JsonResult MutatePerson(PersonDto person){
    //Call functions by TDD here
    return Json(true);
}

Upvotes: 0

Views: 289

Answers (3)

guillaume31
guillaume31

Reputation: 14064

It might be just me, but I have the feeling that you're starting off with little idea of what your global system should look like in terms of layers, modules and the dependencies and interactions between them.

TDD's emergent design sure works at the level of a small object graph, but you won't get away without doing some amount of overall architectural design first (not big upfront design, but enough to get you started).

With that in mind, I think you'll have a far better idea of what to test.

Once you've figured that out, I think you should :

  • Learn about object-oriented unit testing techniques, and by unit testing I mean testing things in isolation. Roy Osherove's Art Of Unit Testing is an excellent place to start for a .NET developer.

  • Learn about architecture-level TDD strategies. With the articles you read you certainly got an idea of how to do TDD in the small, but you need a more global approach : what should you TDD first, in what order, etc. A book like GOOS might help you in that department.

Upvotes: 1

Morten
Morten

Reputation: 3854

Using TDD, you should use interfaces as arguments. Interfaces can be mocked, and with a mock you test the MutatePerson method, and ONLY that. In a unit test, you only want to test how a method reacts to input, not how the object reacts to the method. If you test how the DTO object behaves as well, you are writing an integration test.

So, use the interface of PersonDto (create one if it doesn't exist). And use that as method argument instead of the concrete class.

Upvotes: 1

Brian Agnew
Brian Agnew

Reputation: 272307

You've described the objects involved, but not the operations.

Presumably you need a read() operation, a write() operation. Perhaps a list() operation ?

All of the above should have tests associated with them e.g.

testCanReadViaId();
testCanThrowExceptionOnReadingInvalidId();
testCanWrite();

etc.

For a lot of work you should mock your datasources etc. and position (say) hardcoded data under your persistenc elayer such that you don't rely on a database. However for something like the above I would definitely test the basic database interaction.

As such you may need to (initially) point a test suite against a database with canned data. If you want to be more flexible, then your test setup code could write the entities into the database first, prior to running the tests.

Your tests should test different permutations of data and operations e.g. in the above I've suggested a test to read an object via a valid id (say, 1) and a similar operation against an invalid id (say, -1). You may also want to check different data combinations (e.g. does everything work if the email address isn't populated - this may be valid if the database column is nullable)

Upvotes: 1

Related Questions