How to write Use case(s) & Test Driven Development for binding a gridview Example_问答_开发者

I'm still trying to understand and use Use Cases and Test Driven Development, but having a hard time crossing the line. I'm hoping someone can provide a good example of how setting a datasource and/or databinding a gridview could be accomplished using Test Driven Development.

Here is my pseudo approach at it.

Create an aspx page and add the gridview control to it.
create a method in the code behind called BindGrid(datacollection,gridview) that passes the collection and gridview to a method in a class outside my website so I can actually write the Unit test for the method, and returns a databound gridview.
On the BindGrid method, I right click and select "Create Unit Test" which creates a new test project fo开发者_如何学编程r me with an outline test for my BindGrid() method.
Now I guess there are a number of test I could write, for example: testTrueDataCollectionBindstoGridView() to see if the collection datatype actually binds? I'm not sure the other test to write?

This is how I currently understand I would go about TDD and Unit testing my example. It feels very clumsy and I'm hoping for some feedback as to what I'm doing wrong, and ideas for improvement.

Thanks

Update:

I've decided to try to simplify my question in hopes of getting more ideas.

How would you go about writing a test for a collection binding to a control? For example say I wanted to bind a dictionary to a drop down list. What test should I be writing, and how would I go about writing them?

Thanks

To some extent, your question describes why the ASP.NET MVC frameworks was created. It is very difficult to write tests against the ASP.NET Web Forms model (of which the GridView is part of). Also, you seem to be close to writing tests to test the Framework itself, not the code you are writing. If you go too far down that path you will write tests forever and never release any code. It would be more productive, in this case, to seperate out whatever code you used to generate the collection you are binding to the GridView and thouroughly test the scenarios around creating that (and especially any exception conditions and possible conditional logic) and trust that the framework binds the data to grid correctly. If the data generation method can produce any exceptions that you want to handle at the UI-level, try test how your code handles that, but again, this is where the MVC frameworks are helpful, b/c it is extremely difficult to test code that needs to be run within the Web Forms lifecycle.

Just speaking in general terms, since I'm mostly doing Java these days and not .NET stuff. I find that TDD does feel rather clumsy at first for most people, but give it some time, and see if you like it or not.

As far as writing tests, take this general approach. Create a method that you want to test, but without any body to it. Create a test that exercises some particular behavior, and keep it simple. Run the test, and it should fail (run red, assuming your IDE does that). Then, write the line or couple lines of code that make the test succeed (go green). Now, write another test, and repeat. If you have conditionals, make sure all paths are tested. That is, write one path, then the other, writing the test for each first.

When you have a method that works the way you want, you can now refactor it to your heart's content, since the test will always be there to check your work. Look at the method. Perhaps there's 4-5 lines that go together, and could be pulled out into a method. Give the method a good name, so that when you're reading the calling method, the name tells you what's going to happen without drilling in. There are other possible refactorings, especially inasmuch as you can see design patterns that you can leverage.

Make sure you re-run the tests frequently as you proceed with your refactoring.

TDD is about adding functionality. It encourages minimal logic in UI components - mostly they should be pure delegates to the code that does the real work, that you can test.

I would recommend, for the purposes of learning TDD, don't bother writing tests about UI behaviour (eg binding data to a control).

To learn TDD effectively, I think a good place to start is try a few code katas. A code kata is a small problem which you do repeatedly. The solution you develop is not the important thing - learn from the process of getting to the solution. So do the problem 10 times, and deliberately choose different designs for the solution each time. TDD is about the process.

There is a list of katas here: http://codingdojo.org/cgi-bin/wiki.pl?KataCatalogue

The Roman Numerals kata is a good one, but just pick one that appeals to you.