TAF Cookbook

TAF Cookbook

The Aras Testing Automation Framework (TAF) is a powerful tool, but one that requires some technical acumen to wield. Based on Selenium, developers and testers will need time to familiarize themselves with this environment. While documentation is included with every TAF release, we here at Aras Labs thought we’d highlight some of our more commonly used commands.

These examples are drawn from TAF 1.4, run against an instance of Aras Innovator running version 12, service pack 10.

Basic Navigation

While you won’t usually need to test that the basic navigation of Aras Innovator is working, it’s easiest to think of writing TAF tests as writing a script for someone to follow, opening things up and looking at values within the program. As such, you need to be able to get around, and that means working with the navigation panel. The first step of many tests will be to open it and go somewhere. This makes use of Aras.TAF.ArasInnovator12.Actions.Chains.PinChains and Aras.TAF.ArasInnovator12.Actions.Chains.OpenChains.

Actor.AttemptsTo(
                Open.NavigationPanel,
                Pin.NavigationPanel
);

As a side note, this is also helpful as an absolutely minimal "test", just to make sure that your configuration is correct. It’s the TAF equivalent of “hello world” or tapping the microphone and asking “is this thing on?”

These next two commands will open a search grid, and then search up and open a particular item from that grid. We’ll use Parts and an item called MP0101, but spell out how to change these commands to look for whatever item you have in your configuration.

//Open a search grid from toc
Actor.AttemptsTo(Open.SearchPanel.OfTocItemWithPath("Design/Part").BySecondaryMenu);
//Open an item from the search grid           
Actor.AttemptsTo(Open.Item.InMainGrid.WithValueInCell("Part Number", "MP0101").ByContextMenu);

When opening the search grid, you need to enter the whole path to the item you want. In our example, Part is under Design, so we use “Design/Part” to find it. When searching for a particular item, you need both the property you want to search on, and the value of the item you want. Important note: You use the label of the property, not the name of the property. “Part Number” for example is the label of the property named “item_number” but you can’t feed “item_number” into this command. Both commands require you to be using Aras.TAF.ArasInnovator12.Actions.Chains.OpenChains.

Working With Forms

You’re now on the form you want. Let’s lock it quickly so we can make some edits.

Actor.AttemptsTo(Edit.OpenedItem.ByButton);

Note: On this form, the button to make edits is called Edit. In other places, it might be a Lock symbol, in which case you’d use the following:

Actor.AttemptsTo(Lock.OpenedItem.ByButton);

Edit is in Aras.TAF.ArasInnovator12.Actions.Chains.EditChains while lock is in Aras.TAF.ArasInnovator12.Actions.Chains.LockChains.

Once you’re in the form, you need to keep track of what properties are available to you. At this stage, TAF is looking at the user interface, and you want to test that the right fields are available to the user. The next two commands work together, finding the form you need to edit and then setting a new value on the form.

var form = Actor.AsksFor(ItemPageContent.Form);
Actor.AttemptsTo(Set.NewValue("Madebot Replicated").ForProperty("name").OnForm(form));

You can set as many of the fields on this form as you like, adding new lines starting “Actor.AttemptsTo(Set…” after these. Two important notes: First, there are a variety of forms you might wind up on. ItemPageContent.Form is what you’ll use for a straightforward part like this, but keep an eye on that line! Second, the value of “.ForProperty()” needs to be the actual name of the property, not the label!

Now, we can save and close. You’ll want to be careful about when you save changes in your tests: ideally, you want to clean up after yourself so you can run tests again and again without manually resetting any data. However, you often do want to save changes, so you can see how the rest of your system handles things. Say, creating a new item and checking that a sequence is applied properly, or saving one item and checking that the inherited property on another item picks up your changes. These are in Aras.TAF.ArasInnovator12.Actions.Chains.SaveChains and .CloseChains, respectively.

Actor.AttemptsTo(Save.OpenedItem.BySaveButton);           
Actor.AttemptsTo(Close.ActiveItemPage.ByCloseButton);

A lot of what we've done so far is about moving around Aras Innovator and manipulating the forms. This is necessary for getting into position to check values, and for custom itemtypes it's well worth checking that you can save an item and it will behave the way you want. That also means checking the value after the fact though, and sometimes you just want to check the value without doing any editing in the first place. For that use case, there's ChecksThat().

form = Actor.AsksFor(ItemPageContent.Form);
Actor.ChecksThat(Value.Of(BaseFormElements.FormattedTextOfField("name", form)), Is.EqualTo("Madebot Replicated"));

You'll want both Aras.TAF.ArasInnovatorBase.Questions.Content and Aras.TAF.Core.NUnit.Extensions for this.

That second line is doing a lot. The ChecksThat() method is powerful, with a lot of usages. We don't have space in this article to go into every way you can make use of ChecksThat(), but we do have room to break down what the above lines are doing. First, "Value.Of(BaseFormElements.FormattedTextOfField())" is going to look at what's in a text field. FormattedTextOfField takes two inputs, the name of a property (not the label!) and a form. Form we get from asking for it in the first line, and the property name we can get by looking at the itemtype. "Is.EqualTo()" is our known good value, the thing we're testing against. BaseFormElements has a lot of methods under it, and you should adjust which you're using depending on what kind of input you're targeting, from text fields to checkboxes to dropdown menus! ChecksThat is fairly flexible as to what it compares. The Check Yourself method is sadly still in development.

A note on best practices: You generally want to use easily changed variables, or better yet external files with test data that you can load in, rather than hardcoding the values you want to use. These examples use hardcoded values so that it's easier to see what each command and method is doing, and what kind of input it needs, but this would become frustrating to maintain or update if done like this on a large scale.

Bonus: Screenshots 101

One more thing: TAF can take screenshots of the UI as it’s proceeding through a test. This is invaluable for capturing details you might not think to test for, like whether everything looks the way you want it to and is laid out properly. It’s also handy when writing tests, since this way you don’t need to sit and watch the test run through every time to know what things looked like right before a line that fails unexpectedly. While screenshots have a valued role in a fully written and working test, they’re also helpful when writing the test.

Aras.TAF.Core.Selenium.Actions.ScreenshotActions.MakeAndSaveScreenshot snap = new Aras.TAF.Core.Selenium.Actions.ScreenshotActions.MakeAndSaveScreenshot("test","C:/test");
Actor.AttemptsTo(snap);

Conclusions and Congratulations

There are many more actions and options within TAF, but these are some good starting points. In particular, screenshots can be combined with human testing to set up quick comparison shots for areas you haven’t fully automated yet. Take some time to explore the documentation, or if there’s a specific piece of the UI you want to work with go ahead and ask about it in the forums. If you’re using TAF in an interesting way, please comment on this post, we’d love to hear about it!