Angular JS Tips 1-6

A collection of 6 of the best Angular JS Tips and Tricks

Tips #1 : Link - href

If you want to use AngularJS markup inside your links, you have to use ng-href instead of href. The reason is that it takes time for AngularJS to parse all HTML, and this means that if the user is quick he/she can click the link before it is actually parsed. This would result in a 404-page. So, instead of writing this:
<a href="http://www.someurl.com/{{hash}}"/>
you should write this:
<a ng-href="http://www.someurl.com/{{hash}}"/>

Tips #2 : Image - Src

This is similar to using ng-href instead of href. Whenever you insert images and want to use Angular-markup, you have to use ng-src. Just like this:
<ul id="preview" ng-repeat="image in images">
      <li><img ng-src="{{image}}" /></li>
</ul>

Tips #3 : How to check if form data changes or not

I needed to implement a functionality that would warn the user about changed data in a form when the user tried to navigate away from the form. Luckily, in AngularJS this is very easy. You just use the $dirty variable. Just like so:
$scope.back = function($event, ConfirmBackText) {
  $event.preventDefault();
  if ($scope.mainform.$dirty) {
    if (confirm(ConfirmBackText)) {
      window.history.back();
    }
  } else {
    window.history.back();
  }
};
Notice, that I check whether or not $scope.mainform.$dirty is true or false. If it is true, I pop the confirm dialogue.

Tips #4 : Two callback at once

AngularJS allows you to watch a variable and will call a callback whenever its content is modified. But what if you need to watch two variables at once? You can write this:
function callback() {
  ...
}

$scope.$watch('a', callback);
$scope.$watch('b', callback);
But you can also write this, which is more elegant:
$scope.$watch('a + b', callback);
The value of “a + b” will change whenever either a or b changes. Therefore you watch both variable at once.

Tips #5 : Syntax of directives

The tutorial of AngularJS writes directives like this: "ng-model". But you can also write: "x-ng-model", "ng:model", "ng_model", "data-ng-model". They are all equivalent and work the same. I like to use the syntax with "data-" because it is standard-compliant.

Tips #6 : Nuances of ngDisabled

There is actually an ngDisabled attribute that you can leverage for dynamically changing the disabled state of a form control. However, there may still be some confusion as to the different states and values that represent disabled or enabled, so to help clarify I made this simple demo: http://jsfiddle.net/ProLoser/j4EkX/light/
Thanks : Angularjs4u.com

Unit Testing ASP.NET Pages Using WatiN

Unit testing is an integral part of the application design. Unit testing is applied at different levels of the application. In this article we will focus on the User Interface level unit testing. We will use WatiN to test our ASP.NET application. Introduction: Unit testing is an integral part of the application design. Unit testing is applied at different levels of the application. In this article we will focus on the User Interface level unit testing. We will use WatiN to test our ASP.NET application. What is WatiN? WatiN is a tool inspired from Watir (Don't worry I will write an article on Watir very soon) to test web pages. WatiN stands for Web Application Testing in .NET. What are we testing? In this article we will be testing a simple ASP.NET page. The page will demonstrate an agreement acceptance scenario. The user will type his name in the TextBox, click the “I agree” checkbox and then press the submit button. This is a very simple page to test but after you are familiar with the workings of the WatiN framework you can apply the same concepts for testing large pages. Here is the screen shot of our page: Testing the Agreement Page: Add a class library project to your solution and make references to the testing tool (I am using MbUnit but you can use NUnit or VS Team Suite Test Project) and the WatiN library. You can download the WatiN library from the here. Here is the simple test which makes sure that the user has agreed the agreement. [TestFixture(ApartmentState = ApartmentState.STA)] public class TestAgreementPage { [Test] public void test_can_accept_the_user_agreement() { IE ie = new IE(ConfigurationManager.AppSettings["DefaultPageUrl"] as String); ie.TextField("txtName").TypeText("Mohammad Azam"); ie.CheckBox("chkAgree").Checked = true; ie.Button("Btn_Agree").Click(); Assert.AreEqual("Valid",ie.Span("lblMessage").Text); } } The class is decorated with the TestFixture attribute which also makes sure that the tests are run in a Single Threaded Apartment state. This is because the test will launch the Internet Explorer. The IE class contained in the WatiN library does the main work. IE class opens the Internet Explorer and refers to the HTML controls using their name or ID. The line ie.TextField(“txtName”).TypeText(“Mohammad Azam”) refers to the TextBox with the ID “txtName”. When the browser is launched WatiN will write the text “Mohammad Azam” inside the TextBox named “txtName”. This will be done right before our eyes and you would be able to see WatiN typing text into the TextBox. Then the CheckBox with the ID “chkAgree” will be checked. Finally, WatiN will press the submit button and the form is submitted. If you run this test it will fail. This is because the Label named “lblMessage” is never set to “Valid”. Let’s do that in the page code behind. protected void Btn_Agree_Click(object sender, EventArgs e) { lblMessage.Text = "Valid"; } Now, if you run the test it will pass. But, something does not seem right. Let’s remove the following line from our test. ie.CheckBox(“chkAgree”).Checked = true; This means we are not going to mark the CheckBox as checked. If you run the test again it will pass. This is not right! The test should only pass when the CheckBox is checked. Let’s make a change to the code behind of the page. protected void Btn_Agree_Click(object sender, EventArgs e) { if (chkAgree.Checked) { lblMessage.Text = "Valid"; } } Now, the test will only pass when the CheckBox is checked. Programmatically Running the Web Server: In the above example you will need to start your WebServer by either manually running the command line tool or by running the Web Application Project. But, sometimes you will want the unit test project to dynamically start a web server. Let’s check it out how this can be done. First, if you want to start the ASP.NET internal server (WebDev.WebServer) then you can use command line to start it. The syntax is shown below: WebDev.WebServer.exe /port:1950 /path: “C:\Projects\MyWebApplication” You will need to be in the same directory where the WebDev.WebServer exists. By default it is located at: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\WebDev.WebServer.exe Now, let’s use this information to start the server using unit tests. First, here is the required configuration saved in the configuration file (App.config). The BaseTestPage class will use this information to start the server and all the test classes will derive from the BaseTestPage class to use this functionality. Here is the complete code for the BaseTestPage class: public class BaseTestPage { static Process server = null; static BaseTestPage() { if (Process.GetProcessesByName("WebDev.WebServer").Count() == 0) { string webServerExePath = (string)ConfigurationManager.AppSettings["WebServerExePath"]; server = new Process(); Process.Start(webServerExePath, GetWebServerArguments()); } } public static string GetWebServerArguments() { string args = String.Format("/port:{0} /path:\"{1}\"",GetPort(),GetWebApplicationPath()); if (String.IsNullOrEmpty(args)) throw new ArgumentNullException("Arguments is not defined"); return args; } public static string GetPort() { string port = ConfigurationManager.AppSettings["Port"] as String; if (String.IsNullOrEmpty(port)) throw new ArgumentNullException("Port is null or empty"); return port; } public static string GetWebApplicationPath() { string webApplicationPath = ConfigurationManager.AppSettings["WebApplicationPath"] as String; if (String.IsNullOrEmpty(webApplicationPath)) throw new ArgumentNullException("WebApplicationPath is null or empty"); return webApplicationPath; } } We used a static constructor to make sure that the process is not running. If it is not running we make a new process and start it else we use the old process. The GetWebServerArguments(), GetPort() and GetWebApplicationPath() are just helper methods to improve the readability. Finally, you will derive all your unit test classes from the BaseTestPage class as shown below: public class TestAgreementPage : BaseTestPage Now, if you run your unit test project will start the WebServer and then run all the tests. Conclusion: In this article we learned how to unit test our user interface layer. Unit testing the user interface helps us to understand the requirements of the interface and quickly see the expected result based on the user input. If this testing is done manually then it might take a lot of time.

Determining Html Element Visibility with WatiN

I recently started using WatiN to write automated Web application tests for the first time. WatiN is a great and rapidly maturing tool with lots of developer support, and I highly recommend it based on my experiences so far. But after writing several tests of dynamic screen elements I realized the tests weren't verifying everything I thought they were verifying. When you use WatiN "Find" syntax to search for elements and screen text there's no obvious distinction made between hidden and visible elements. The screens I was testing use ASP.NET validation controls to perform client-side validation and include other dynamic elements such as the AJAX.NET ModalPopupExtender. I wanted to verify that these elements were visible and hidden at the appropriate times, and the simplest way of accomplishing this with WatiN was not immediately obvious. After digging around in the API a bit I came up with a method that's simple, robust and seems to perform reasonably well. As demonstrated in the sample tests below, you can simply walk up the element hierarchy checking whether an element or any of its parents are styled with "display: none". 1: using System.Text.RegularExpressions; 2: using NUnit.Framework; 3: using WatiN.Core; 4: 5: [TestFixture] 6: public class WatinTest 7: { 8: [Test] 9: public void PopupDisplayed() 10: { 11: var ie = new IE(); 12: ie.GoTo("http://www.example.com"); 13: 14: Div popup = ie.Div(Find.ById(new Regex("pnlPopup$"))); 15: Assert.IsTrue(IsDisplayed(popup)); 16: } 17: 18: [Test] 19: public void ValidatorDisplayed() 20: { 21: var ie = new IE(); 22: ie.GoTo("http://www.example.com"); 23: 24: Span validator = ie.Span(Find.ByText("Required field")); 25: Assert.IsTrue(IsDisplayed(validator)); 26: } 27: 28: public bool IsDisplayed(Element element) 29: { 30: if (string.Equals(element.Style.Display, "none")) 31: { 32: return false; 33: } 34: if (element.Parent != null) 35: { 36: return IsDisplayed(element.Parent); 37: } 38: return true; 39: } 40: } The first test case (PopupDisplayed) searches for the div element representing a modal popup panel by the element id. It uses a regular expression since the ASP.NET control ids for nested controls are unwieldy and variable. In this test we are checking whether the div itself is displayed, but this method would also work for any control contained by the div (such as a submit or text input element). The second test (ValidatorDisplayed) searches for the span element representing a RequiredFieldValidator by the validation text contained in the span. Some caveats apply when using this method: It works only with embedded CSS styles. If the "display: none" style was applied using a CSS class contained in a style sheet the WatiN Element.Style property would NOT automatically reflect this. It doesn't determine true element visibility--only whether the element is displayed. Elements may also be hidden using "visibility: hidden", occluded by other elements with a higher z-index, or moved offscreen using the position style. As a side note, I highly recommend that you grab the Internet Explorer Developer Toolbar and take some time to understand the WatiN page model before writing many tests.

Unit testing aspx pages with WatiN tool

I just read a post on GridViewGuy blog that introduces a great tool for testing aspx pages - WatiN, and it really grabbed my attention. To put it in short, WatiN is a framework that will let you write unit test in order to test aspx pages functionality. "Inspired by Watir development of WatiN started in December 2005 to make a similar kind of Web Application Testing possible for the .Net languages. Since then WatiN has grown into an easy to use, feature rich and stable framework. WatiN is developed in C# and aims to bring you an easy way to automate tests with Internet Explorer." WatiN is written in C# and is licensed under Apache License 2.0. The important features are the support for Ajax pages, frames and iframes and popup dialogs. It supports testing in Internet Explorer 6, 7 and 8 and Firefox 2 as well. Now let's see some example. Take a look at the sample code that will search for keyword "MSForge" on Google in both IE and Firefox browsers. [Test] public void SearchForMSForge() { using (IBrowser ie = BrowserFactory.Create(BrowserType.InternetExplorer)) { ie.GoTo(http://www.google.com); ie.TextField(Find.ByName("q")).Value = "MSForge"; ie.Button(Find.ByName("btnG")).Click(); Assert.IsTrue(ie.ContainsText("MSForge")); } using (IBrowser firefox = BrowserFactory.Create(BrowserType.FireFox)) { firefox.GoTo(http://www.google.com); firefox.TextField(Find.ByName("q")).Value = "MSForge"; firefox.Button(Find.ByName("btnG")).Click(); Assert.IsTrue(firefox.ContainsText("MSForge")); } } As you can see it is similar to "classic" unit testing. Test methods should have [Test] attribute and have to return no data. You simple create a new instance of a browser and access any DOM element. After simulating a search behavior of a user, we can examine the results by well known Assert class. You can find more information on WatiN website and download WatiN package with binaries and samples from here. Happy testing :)
Powered by Blogger.