4 Replies - 11537 Views - Last Post: 04 January 2013 - 07:09 PM

#1 Nakor  Icon User is offline

  • Professional Lurker
  • member icon

Reputation: 445
  • View blog
  • Posts: 1,501
  • Joined: 28-April 09

Test Driven Development

Posted 14 July 2012 - 06:58 AM

So lately I've been trying to teach myself new (to me) methods of doing things. I've been learning about design patterns with some success. I get how to use most of the ones i've looked at to one degree or another, now it's just a matter of learning when I should use them and when not to.

One thing i'm having a hard time wrapping my head around though is Test Driven Development. I understand the basic concept of it and it's something I would like to start implementing at work, however, I have a really hard time figuring out how to get started writing those initial tests. For some reason when I try to figure what test to create my mind just goes blank.

So my question would be do any of you currently use TDD and if so how do you go about deciding which tests to write initially. I think after I got going it would get easier, it's the getting started part that throws me for a loop for some reason. I just got a book on it yesterday and I'm hoping that will help but I thought I'd get some input from actual people who may have used it as well.

Is This A Good Question/Topic? 2
  • +

Replies To: Test Driven Development

#2 Sergio Tapia  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1253
  • View blog
  • Posts: 4,168
  • Joined: 27-January 10

Re: Test Driven Development

Posted 14 July 2012 - 08:24 AM

Quote

I have a really hard time figuring out how to get started writing those initial tests.


This is a very common issue for many developers starting out with TDD. The truth is, it's an art. You have to start with very basic (stupid, even!) things and then with time you'll get a feel for what's worth testing and what's not worth testing.

I've been doing it for 9 months in both MVC3 applications and Rails applications and I still don't feel quite there yet.

For example, start with simple Model unit tests that ensure validations are firing, etc.

It would help if you told us what context you'd be applying unit testing in. A web app? A desktop application? A mobile app?

If you're just starting out, I'd recommend the following book:

Pragmatic Unit Testing in C Sharp with NUnit:
http://www.amazon.co...harp+with+NUnit

Also worth noting nUnit has now been succeeded by xUnit:
http://xunit.codeplex.com/

This post has been edited by Sergio Tapia: 14 July 2012 - 08:25 AM

Was This Post Helpful? 1
  • +
  • -

#3 Nakor  Icon User is offline

  • Professional Lurker
  • member icon

Reputation: 445
  • View blog
  • Posts: 1,501
  • Joined: 28-April 09

Re: Test Driven Development

Posted 14 July 2012 - 06:50 PM

well, like I said, I just got a book that covers TDD, it's called "Test-Drive ASP.NET MVC" from Pragmatic Programmers and covers MVC 2, which I don't really care about since I didn't buy it to learn about MVC but to get some ideas about TDD. It also seems to suggest to start out at a very basic level, testing to make sure that your controller returns the correct view. So that you can confirm that your Index controller is returning the Index View. That almost seems to be taking the testing to an extreme but maybe that's a standard practice when doing TDD in MVC?

But anyway, lets say you were developing a simple page to display a table of data to be viewed by the user. What would the process you'd go through to determine what your tests should cover? At what point do you determine if you need to start refactoring into patterns, such as using a repository class to interact with your data? Or do you start off knowing you're going to be using repositories (or some other specific method) and create your tests according to that? Or should you create the tests without making any assumptions about the final result?

If I knew I was going to be using a ViewModel to pass data to and from the View would I create the primary test for that controller using that non-existant ViewModel, then go about creating the ViewModel and updating the controller to make the test pass? If so then at what point do you start creating the tests for the ViewModel class?

This post has been edited by Nakor: 14 July 2012 - 06:58 PM

Was This Post Helpful? 0
  • +
  • -

#4 Sergio Tapia  Icon User is offline

  • D.I.C Lover
  • member icon

Reputation: 1253
  • View blog
  • Posts: 4,168
  • Joined: 27-January 10

Re: Test Driven Development

Posted 15 July 2012 - 10:55 AM

In all of my MVC3 applications I start off using the Repository patterns and inject as necessary with Ninject. I then use Moq to mock Interfaces (eg. IRestaurantReservationRepository) and use the mocked repo for my test cases.

What you said it correct, start writing broken tests that don't run well and then work towards making them "green" (running). You'll find that following this kind of forces you to write loosely coupled software.
Was This Post Helpful? 1
  • +
  • -

#5 immeraufdemhund  Icon User is offline

  • D.I.C Regular

Reputation: 79
  • View blog
  • Posts: 495
  • Joined: 29-March 10

Re: Test Driven Development

Posted 04 January 2013 - 07:09 PM

I love TDD, i use it when ever I start the back end of most of my programs. I've been told it works with the GUI portion of it, but i can't seem to figure that portion out...that and I think it would be stupid to do that unless your form/webpage populates controls a certain way based on input/output.

I learned my basic understanding of TDD from a book by Robert C Martin. He has some very good tips and pointers on how to get started with it. He talks about it most in his book Clean Code (which has tons of Java examples, but the concept follows through nicely in C#)

So you mentioned an example: "But anyway, lets say you were developing a simple page to display a table of data to be viewed by the user"

so displaying it is super simple..that part should not be tested. But the data on the other hand can be tested. You can test that you have a solid connection to your database. I always have a iDatabase which will have all my high level commands, plus one (GetAllCustomers(), GetThis(), GetThat()) The plus one is GetAllTables(). I then extend it with what ever type of db i'm talking with only, but i don't implement any of those functions. From there I start my tests. TestCanConnect() - that one does a test to see how many tables were returned and I use Assert to make sure that the table names and table count match. This way if the table structure changes I know to take a gander at my tests to make sure that the structure is the same and the data returned is accurate. The nice thing about this test is that your database can be empty as long as you have the tables at least set up.

So that is the first test. The next part of that test would be to make sure you can get back the desired "All data" stuff for every table that you will be accessing to return back that desired bit of information to show to the user. Create a SQL statement to insert into those tables, then count the results and verify the data. once that is verified delete that data out of your tables. Lastly you work on the data that is to be outputed to the user. This is where you could potentially have more than one test for different scenarios. Once you get your tests wrote you will have done a number of changes to your structures to help you test. The end result is that you will have something like

private void DisplayDesiredData(iDatabase db)
{
    var data = db.GetDesiredData(param1, param2...etc);
    datagrid.DataSource = data;
}



you won't even need to open up your form to verify the data is right if you've wrote enough tests. That is my personal test. If I feel confident enough to run my program and the desired data will be present than i will have done my job, and I have wrote enough tests. One bit of advice I can say though is that if you have old programs, don't go back and write tests unless you plan on changing a few methods. Tests are a wonderful thing and it helps your code out, but it also makes you feel bad when you look back at old code because you can't test it, and if you need to make changes it takes you a bit longer.

Last bit I want to mention is a personal experience where one of the managers of the company I worked for wanted me to write a program to gather a bunch of data and put it into excel for him. So i started writing my tests to gather up the data. I had 30 some odd tests and could run them all and it would all pass. I had to put that program on the back burner for about a month because another project came up that HAD to be finished yesterday (as with all emergencies :/ ) When i finished it i went back to the other program. I ran my tests and about 15 passed. During that one month period another manager decided to make some big changes to the tables, which broke a number of my tests. I didn't have to do any debugging to know what had changed, my tests told me what changed. I was able to talk with that person who made the changes, find out what got changed and fix my tests so that they all worked again. So it ends up also being a debugging tool for you because if your program stops working after a little while of working perfectly you can run your tests and find out what changed.

There are times though that writing a test for some math thing only needs to be done once and not again, once you get it right you don't have to come back to it ever. For that case I have a project that has nothing but tests, and no real code... just a simple class called program, and about a billion public functions. I have a test for each of those functions which are all math related in nature. I'll then take the logic from that test project and put it in my program I'm working on. well that is my 2 cents worth.
Was This Post Helpful? 3
  • +
  • -

Page 1 of 1