Comments on: Testing UI – part 1

By: Andrii

Andrii — Thu, 15 Dec 2011 13:40:26 +0000

I think in the test you’re missing :

loginPage.login();

before

assertEquals(“user/pass”, log);

By: Eric

Eric — Tue, 19 Apr 2011 23:10:23 +0000

This is a good presentation of a controller communicating with a view using data binding. But I have two concerns. One thing I do not like about data binding is that it can lead to subtle bugs regarding time. That is, when you have multiple data items that work together, you want to be sure that all of them pertain to the same entity. For example, that they all belong to the current customer, not a previous customer that the user clicked through. The other concern I have is with complex user interfaces. If there is some complex manipulation of the user interface, that requires more that just accessing the text property of a UI component, such as creating additional components on the fly, the programmer would have to decide how to allocate the code between the view and the controller. That might make for some difficult decisions. It might also tempt the programmer to have the controller access the View. In any case, thank you for the presentation.

By: Sagar

Sagar — Thu, 23 Apr 2009 10:00:46 +0000

hi misko,can u please suggest any tools where in a tester can identify the color, fonts, fonts size on a UI.

By: Constructor Injection vs. Setter Injection

Constructor Injection vs. Setter Injection — Thu, 19 Feb 2009 18:24:26 +0000

[...] I was building a Flex application and using the Model-View-Controller. Flex XML markup requires that components must have no argument constructors, therefore I was [...]

By: misko

misko — Fri, 19 Sep 2008 17:17:22 +0000

@CJ

I am sure in the bast you have seen the dependencies go all different ways. But I bet you those ones are hard to test.

A View is rendering, that is hard to test. Unlikely that you will be able to assert anything interesting. Not to mention since it is rendering it needs some graphics context and so it will not be a unit test.

A Controller has lots of interesting code/behavior in it which you want to test. But if controller knows about the view than Controller is now hard to test since dependencies are transitive. That is why we need to break that dependency.

Now you are right, we need to be able to communicate data from Controller back to UI. So to do that we use data bindings. (Or events). This way we can easily unit test the controller and don’t have to pay the expensive view set up.

Now many systems have this backwards, or even have circular dependencies. My guess is that those systems are also not easy to test.

By: CJ

CJ — Fri, 19 Sep 2008 15:04:53 +0000

Sorry, my ascii drawing got screwed but html preprocessor or something. I drawed this:

View ← Controller → Model

By: CJ

CJ — Fri, 19 Sep 2008 15:02:50 +0000

I did not get it about Model-View-Contoller. You say Controller shouldn’t be dependent on View, but aren’t contollers exist exactly for briding views and data, and interfacing them to rest of the system? Programs I worked with had dependencies like this:

ViewModel

How does view know what visual elements it’s to change when model changes? Via observing model’s events? Or how?

By: misko

misko — Tue, 19 Aug 2008 04:47:16 +0000

Power of data bindings.

Calling login() will change the controller.showError to true. Notice the code below.

visible="{controller.showError}"
color="#FF0000" fontWeight="bold"/>

The visible property is data bound to controller.showError which will result in the error message displayed.

See the login() method can take a while to decided if the login was successful an so it can not return true or false. The showError field can be changed some time later.

Love those data bindings!

By: Jonathan

Jonathan — Mon, 11 Aug 2008 22:22:02 +0000

In the LoginPageTest, won’t you need to call the controller’s method:
public function login():void

Without calling void() how will the showError be populated?

Also, would you use a different design in reality for setting the error message?
You have:
showError = authenticator(username, password);

But instead would you catch an authentication exception, and set the error based on that. If the authenticator returns true when it succeeds, the showError will equal true, which is non-sensical.

By: misko

misko — Sat, 02 Aug 2008 17:13:09 +0000

Fixed the images. Thanks for pointing it out…