UI interface and TDD babysteps

Question

OK, having tried my first TDD attempt, it's time to reflect a little and get some guidance, because it wasn't that successful for me. The solution was partly being made with an existing framework, perhaps making TDD less ideal. The part that seemed to give me the biggest problem, was the interaction between the view and controller. I'll give a few simple examples and hope that someone will tell me what I can do better wrong.

Each view's interface inherits from a base interface, with these members (there are more):

public interface IView
{
void ShowField(string fieldId)
void HideField(string fieldId)
void SetFieldVisibility(string fieldId, bool visible)
void DisableField(string fieldId)
void ShowValidationError(string fieldId)
...
}

The interface for a concrete view, would then add members for each field like this public interface IMyView : IView
{
string Name { get; set; }
string NameFieldID { get; }
...
}

What do you think of this? Is inheriting from a common interface a good or bad idea? One on the things that gave me trouble was, that first I used ShowField and HideField and the found out I would rather use SetFieldVisiblity. I didn't change the outcome of the method, but I had to update my test, which I seem should be necessary. Is having multiple methods doing the same thing, a bad thing? On one hand both methods are handy for different cases, but they do clutter the interface, making the interface more complex than it strictly have to be.

Would a design without a common interface be better? That would remove the fieldID, I don't why, but I think the fieldID-thing smells, I might be wrong. I would only make the Show and Hide methods, when needed, that is if they would be called by the controller. This would be a less generic solution and require more code in the view, but the controller code would be a bit more simple.

So a view interface might look like this: public interface IMyView
{
void ShowName()
void HideName()
string Name { get; set; }
int Age { get; set; }
}

Answer 1

At the moment I don't really see the added value of the common interface.

I think a better solution would be to have some properties on the controller class: IsControlXYZVisible. You can then databind the visible property of the control to this property.

And your unit test will test the value of IsControlXYZVisible, which will be easier to acomplish.

I also don't understand why you say you had a bad experience with TDD. I think your application architecture needs more work.

Answer 2

Your question is a little bit obscure for me but the title itself calls for a link :

The Humble Dialog box

And when you ask if it(s bad to have two functions doing the same thing, I say "Yes it's bad". If one is calling the other, what's the point of having two functions ? If not, you have a code duplication, that is a bug waiting to sprout whenyou update one and not the other.

In fact there is a valid case where you have two nearly identical functions : one that check its arguments and one that does not but usually only one is public and the other private ...

Answer 3

What do you want to test? Whether Show* will make an widget in the UI visible? What for?

My suggestion: Don't try to figure out if a framework is working correctly. It's a waste of time. The people who developed the framework should have done that, so you're duplicating their work.

Usually, you want to know if your code does the right thing. So if you want to know if you are calling the correct methods, create mockups:

public class SomeFrameworkMockup extends SomeFramework {
    public boolean wasCalled;
    public void methodToTest() {
        wasCalled = true;
    }
}

Build the UI using the mockups.

The second thing to test is whether your algorithms work. To do that, isolate them in simple helper objects where you can all every method easily and test them with various inputs.

Avoid the external framework during tests. It only confuses you. When you've built a working product, test that using your mouse. If you find any problems, get to the root of them and only then, start writing tests against the framework to make sure this bug doesn't appear again. But 90% of the time, these bugs will be in your code, too.

Answer 4

@Aaron

What do you want to test? Whether Show* will make an widget in the UI visible? What for? Don't try to figure out if a framework is working correctly.

I don't want to to test the framework, but the behavior of how I use the framework. Which I think is how you should be doing TDD? So I want to ensure verify that I remember to hide this control and show the other one.

Avoid the external framework during tests. It only confuses you Perhaps calling it a framework is that the correct term, a set of base classes for the view, controllers and other classes might be more descriptive. But I can't avoid the "framework" as the view has to implement interfaces from the "framework" and the controller also has to inherit.