So I just burned away a day of my life tracking down why my TypeScript definition files were giving errors on the Union type definitions (eg, function(value:string|number){/*...*/}).
After much searching around, it seems to be a Resharper 9.0 problem. If you look under the type script section, up to version 1.3 is supported so this makes sense. However, I could not figure out how to disable just the TypeScript stuff in studio. So, then I decided to see if there was an update to resharper to handle the new language version.
Using the Resharper menu item and checking for updates kept failing with an error. So I went to jet brains to see about updating from there. I couldn't find anything for updating, only downloading full version, which is apparently how you update. After the installer launches, you are prompted to update installed features or install new features freshly.
I eventually stumbled upon a blog post explaining that the update from 9.0 to 9.1 is jacked. I don't mind that it doesn't work, however, I had to use google to find this post; it should have been more prevalent on the web site IMO.
I have been looking into the CodedUI project template in Visual Studio for testing some web applications. I had a requirement to automate a browser without using Visual Studio / CodedUI and investigated Selenium directly. I really, really don't like the Selenium syntax for automation, and while I do like CodedUI's syntax better, I still do not like it. I have created some simple extensions to allow a more fluent searching syntax along with some helper classes that can be used to quickly create Page Models. These extensions are similar to CUITe.
In this article, I assume that you are familiar with UI testing and the page model approach (see my previous post on the topic). I will discuss how I've applied page modeling to SPA-type sites and how the fluent syntax can make searching for elements way more terse.
To begin, I would like to stress that the type of testing that should be done in the UI layer should be scoped to testing the UI functionality and behavior. It should not be used to test a system's business logic or any other logic which is outside the scope of the UI. Business logic tests should use Unit Testing. Some of the things we should be testing are:
Does an element show or hide as a response to some user action. Eg, when clicking a close button on a dialog, does the dialog close within 3 seconds.
When an input has an invalid value, does the validation show the user an expected message.
Does a information screen have a valid value for each property. Eg, suppose we have a readonly display of a user's Address information. Do all of the fields have a non-blank value?
Does the navigation follow expected flow? Eg, In a wizard, after completing step 1 and clicking the Save & Continue button with valid form values, does the page transition to step 2?
Things that we will not test include:
After clicking save, did the entry appear in the database?
Did some business-calculated field calculate correctly based on some input?
Of course these are just a few examples of the things we will and will not be testing.
So, here's a simple example site:
The test will check that the page loads with the hidden div display:none (not visible on the page). Then, it will search for the open button, click it, and verify that the div becomes visible. Then we'll close the div and check that it disappears. Very simple.
We'd write a test like this using the page model pattern (discussion of the used models afterward):
[TestMethod]
public ToggleHiddenDivTest()
{
PageBaseModel pageModel = new PageBaseModel(BrowserWindow.Launch("http://path/to/simple/page"));
Assert.IsFalse(pageModel.ToggleArea.IsVisible(), "The toggle area should start hidden.");
ToggleAreaModel toggleModel = pageModel.OpenButton.Click();
Assert.IsTrue(toggleModel.IsVisible(), "After clicking open, the toggle area should be shown.");
Assert.IsFalse(String.IsNullOrWhitespace(toggleModel.DisplayText), "The toggle area should have non-empty display text.");
toggleModel.CloseButton.Click();
Assert.IsFalse(pageModel.ToggleArea.IsVisible(), "The toggle area should hide after pressing the close button.");
}
The models we'll use represent the various 'controls' on the page. Page modeling originated when web sites were more or less a page to page transition to accomplish some task. Now-a-days, we find SPA like sites where a single page may be used to accomplish a complex task without page transitions; instead we hide and show regions of the page. Any region on a page which represents a well defined control will have page model. You could think of this as 'control' modeling instead, but we'll use the term Page Modeling as it is the standard terminology for this approach.
To start, I usually have a model that represents the entire page and call that the PageBaseModel or something similar to indicate it is a base model for the entire page.
When forming page models, I typically take the approach of protected properties for the elements used to implement some behavior on the control and expose public properties and methods to interact with the control and get state information or transition models.
In this example, the HtmlDocument is protected as it represents some technology specific container for this control. The ClickOpenButton method is used to transition between models and returns a ToggleAreaModel as the result of clicking. This represents the most likely next model that the user will interact with. Finally, there are properties that get the toggle area inner page model as well as the currently displayed text in the toggle box.
public class PageBaseModel
{
protected readonly BrowserWindow Parent;
protected HtmlDocument DocumentWindow
{
get { return new HtmlDocument(this.Parent); }
}
protected HtmlButton OpenButton
{
get
{
HtmlButton ret = new HtmlButton(this.DocumentWindow);
ret.SearchProperties.Add(HtmlControl.PropertyNames.Id, "openButton", PropertyExpressionOperator.EqualTo);
return ret;
}
} public PageBaseModel(BrowserWindow bw) { this.Parent = bw; }
public ToggleAreaModel ToggleArea { get { return new ToggleAreaModel(this.Parent); } }
public ToggleAreaModel ClickOpenButton() // need another method to test if the button is visible / enabled / has a clickable point.... { Mouse.Click(this.OpenButton); return new ToggleAreaModel(this.Parent); } }
public class ToggleAreaModel : PageBaseModel { protected HtmlDiv Me { get { var ret = new HtmlDiv(this.DocumentWindow); ret.SearchProperties.Add("id", "hiddenDialog", PropertyExpressionOperator.EqualTo); return ret; } } protected HtmlSpan DisplayTextSpan { get { return new HtmlSpan(this.Me); // only span in the toggle area } }
protected HtmlButton CloseButton { get { HtmlButton ret = new HtmlButton(this.Me); ret.SearchProperties.Add(HtmlControl.PropertyNames.Id, "closeButton", PropertyExpressionOperator.EqualTo); return ret; /*
Assume there was no Me and you'd like to do the same thing...
*/ var container = new HtmlDiv(this.DocumentWindow); container.SearchProperties.Add("id", "hiddenDialog", PropertyExpressionOperator.EqualTo);
HtmlButton ret = new HtmlButton(container); ret.SearchProperties.Add(HtmlControl.PropertyNames.Id, "closeButton", PropertyExpressionOperator.EqualTo); return ret; } }
public ToggleAreaModel(BrowserWindow bw):base(bw) { } public string DisplayText { get { return this.DisplayTextSpan.InnerText; } }
public bool IsVisible() { return this.Me.TryFind(); }
public PageBaseModel ClickCloseButton() { Mouse.Click(this.CloseButton); return new PageBaseModel(this.parent); }
}
As you can see, most of the properties require at least three lines of code and a variable assignment to return. If the elements required additional search properties, you'd have lots of typing as each additional property would require it's own statement. If you need to find elements 'along they way', you have create a variable and the new object and set the search properties so that you can use it in the constructor in the new object........ yikes.
Further, this feels 'backwards' to me as I'm creating the element from which to search and passing in the scope and searching criteria. I'd prefer to start with a parent scope and create a search tree with the ability to chain elements along the way. I've created a github repository containing the extensions and they are also available on nuget (under pre-release at time of writing).
With the extensions, I can now write the model as:
public class ToggleAreaModel : PageBaseModel
{
protected HtmlDiv Me
{
get { return this.DocumentWindow.Find<htmldiv>("hiddenDialog"); }
}
protected HtmlSpan DisplayTextSpan
{
get
{
return this.Me.Find<htmlspan>();// only span in the toggle area
}
}
protected HtmlButton CloseButton
{
get
{
return this.Me.Find<htmlbutton>("closeButton");
/*
Assume there was no inheritance and you'd like to do the same thing...
*/
public ToggleAreaModel(BrowserWindow bw):base(bw)
{
}
public string DisplayText
{
get { return this.DisplayTextSpan.InnerText; }
}
public bool IsVisible()
{
return this.Me.TryFind();
}
public IClickablePageModel<PageModelBase> CloseButton
{ get { return this.CloseButton.AsPageModel(return new PageModelBase(this.parent)); }
}
}
Notice how compact it becomes even when chaining additional properties.
There is more to the extension library, but here's the fluent syntax portion. I'll be diving into the Page Modeling and Wrapper classes in another post.
I was trying to setup some Email addresses for a domain I recently purchased and had to hunt around to figure out how the Fastmail integration works with DNSimple (services from which I purchased the domain name).
Here's what I had to do...
Log in to dnsimple and navigate to the domain you want to create email addresses for. (https://dnsimple.com/domains/yourdomain.com)
Click the services button on the left nav
Click the Add or edit services link
Find Fastmail in the list and click Add
This adds a few records, but not enough
Go to Fastmail and login to your account.
If you have a premium account, Click Advanced after you click user name in the top left
Click Virtual Domains link
Under the Domain section, add your domain. See Fastmail docs about the subdomain and other options. You can use defaults for now.
Create your alias (eg, info@yourdomain.com => you@youremail.com)
Check the SRS checkbox
Go down to the DKIM signing keys and copy the public key
Go back to DNSimple and add a TXT record with
Name = mesmtp._domainkey.yourdomainnamehere.com
Content = public key copied in step 10
It took a while for everything to propagate so give it an hour or two and see what happens. This took me about a hour or so to get working so hopefully it helps someone.
On a different note, I will probably cancel the fastmail account in favor of sendgrid.
In a previous post, I looked at MVVM with MVC and how they can be used together in a modern web situation. With this approach, the View Models are unit testable so that the User Interface can be tested without needing to be created.
So, what happens if you already have a UI? Or, you want to test the UI before creating it, how do you do said testing? This is where page modeling comes to the rescue. First I'll introduce page modeling at a high level, then I'll investigate several common scenarios and how you can use page modeling with MVVM to create an awesome, testable UI.
Page Modeling
The topic of page modeling has been around for quite some time and is popular with Selenium based testing solutions. I like to describe page modeling as the process of:
Identifying components of a user interface
Describing the observations (properties) and behaviors (methods) of that component
Understanding how more complex components are composed of other components (simple and/or complex).
At its core, page modeling is breaking down a UI into components, each with well defined behaviors (methods) and observations (properties). Let's look at an example.
Customer Search Control
Let's say I have a Customer Search control that has a
First Name Edit
Last Name Edit
Search Button
Results Table
This can be modeled as three components.
Customer State Manager
The first and last name input boxes would form one component that can store user input about a customer (think: edit screen, new customer screen, search screen all share this component).
First Name Edit
Last Name Edit
Customer Collection Manager
The result table provides the user the ability to edit or delete any given customer in a collection.
Results Table
Search Manager
The search component uses the previously mentioned components and adds a search button (component composed of components). This component would use the first and last name inputs to form a search request. When the Search button is pressed, the component would create a search object, call a WebAPI, get the customer results asynchronously, and populate the result table with these results.
Customer State Manager
Customer Collection Manager
Search Button
Each component would have its own Page Model and likely its own View Model.
Luckily, having created a UI before putting into place any sort of testable design pattern does not mean all is lost. In fact, it is very easy to extract page models from any user interface. Page Models are then easily converted into nearly equivalent View Models. The above exercise of looking at a page and breaking it up into logical components is all that is required to create page models.
Creating View Models from Page Models
Let us continue with the above example. We now have Page Models that look something like the following :
// crude examples of page models
public class CustomerState
{
public HtmlEdit FirstName {get; set;}
public HtmlEdit LastName {get; set; }
}
public class ResultTable
{
public IEnumerable<ResultRow> Rows {get; set; }
public HtmlButton AddCustomer {get; set; }
}
public class ResultRow
{ public HtmlRow InnerRow {get; set;}
public HtmlButton DeleteButton{get; set;}
public HtmlButton EditButton {get; set;}
public HtmlSpan FirstName {get; set;}
public HtmlSpan LastName {get; set;}
}
public class SearchControl
{ public CustomerState SearchCriteria {get; set;}
public ResultTable Results {get; set;}
public HtmlButton SearchButton {get; set;}
}
Let's convert this into a Knockout.js style view model using TypeScript.
class ResultTable { Rows: KnockoutObservableArray<ResultRow>; constructor(rows?:ResultRow[], button?:HtmlButton){ this.Rows = ko.observableArray(rows); if(button){ // binding can go into view or be passed to view model button.addEventListener("click", this.AddCustomer, false); } }
AddCustomer(customerInitializer?:any){ // add it, maybe call back to server, maybe not }
}
DeleteCustomer(){ // delete it // some sort of ajax call to web api to delete this customer } }
class CustomerSearch { State: CustomerState; Results: ResultTable; constructor(state?:CustomerState, results?:ResultTable){ this.State = state || new CustomerState(); this.Results = result || new ResultTable(); }
Search(){ // look inside this.State, form a request, use ajax to call web api // handle success by populating the result table }
}
As you can see, the resulting View Models look extremely similar to the Page Models that were created. Taken further, the Page Models could even have the same methods to encapsulate some behavior of the component.
public class CustomerState
{
public HtmlEdit FirstName {get; set;}
public HtmlEdit LastName {get; set;}
public CustomerState SetFirstName(string firstName)
{
this.FirstName.Text = firstName;
return this;
}
public CustomerState SetLastName(string lastName)
{
this.LastName.Text = lastName;
return this;
}
}
public class ResultTable
{
public IEnumerable<ResultRow> Rows {get; set; }
public HtmlButton AddCustomer {get; set; }
public AddCustomerDialog ClickAddCustomer()
{
Mouse.Click(this.AddCustomer);
return new AddCustomerDialog();
}
}
public class ResultRow
{ public HtmlRow InnerRow {get; set;}
public HtmlButton DeleteButton{get; set;}
public ResultTable ClickDeleteButton()
{
Mouse.Click(this.DeleteButton);
return this.ParentTable;
}
public HtmlButton EditButton {get; set;}
public EditCustomerDialog ClickEditButton()
{
Mouse.Click(this.EditButton);
return new EditCustomerDialog();
}
public HtmlSpan FirstName {get; set;}
public HtmlSpan LastName {get; set;}
}
public class SearchControl
{ public CustomerState SearchCriteria {get; set;}
public ResultTable Results {get; set;}
public HtmlButton SearchButton {get; set;}
public SearchControl ClickSearchButton()
{
Mouse.Click(this.SearchButton);
return this;
}
}
Testing
Regardless of how you design your UI, there is an easy path toward test-ability. Follows are some approaches you can take (in no particular order) to have a testable UI.
Page Models First
If you start by modeling the user interface with page models which describe the behavior of the user interface component (subtly different from view model which knows how to take inputs and translate them to the underlying system, more later), you can create a full suite of GUI tests without any user interface actually being created. Here is what that could look like...
[CodedUITest]
public class CustomerSearchTests
{
protected BrowserWindow startingWindow;
[TestInitialize]
public void TestInitialize()
{
startingWindow = BrowserWindow.Launch("http://mysite.com");
// manipulate the ui until we reach a search screen
}
[CodedUITest]
public void WhenSupplyingAFirstNameFilterAndSearching_ThenAllResultsContainTheFirstNameCriteriaInFirstNameResults()
{
SearchControl search = new SearchControl(startingWindow);
search.SearchCriteria.SetFirstName("Mike");
search.ClickSearch();
Assert.IsTrue(search.Results.Rows.All(x => x.FirstName.Contains("Mike"));
}
}
This would be a great requirements specification for a developer writing the UI. This model even includes the specific UI element types to use (which may or may not be desirable). As the components are completed, the tests can be run and quick feedback is available to the developer as to whether the controls was created correctly. These page models could be easily converted into view models and the system could be tested via the view models.
View Models First
If you start by modeling the user interaction with your system, you can create a full suite of unit tests without any user interface (graphical or otherwise) being created. Given that the above view models were created in javascript, we would need to use a java script test runner. However, for simplicity, imagine the equivalent view models in C#.
[TestClass]
public class CustomerSearchTests
{
[TestInitialize]
public void TestInitialize()
{
// nothing to do
}
If you create your UI first (or inherit an existing UI), we already looked at how easy it is to extract page models and view models.
Conclusion
Regardless of whether you inherit an existing solution with a not-so-testable UI or you are setting out on a beautiful greenfield project, creating tests for your users interfaces (both graphical and non-graphical) is such a simple task, there really is not much reason not to test. This has the side benefit of tested refactoring that bleeds into the business layer. As you test the UI and move into the interaction between the UI and backing system, it is only natural to continue that journey into the systems that power your UI.
