Latest Telerik Test Studio Blog Posts

Functional Testing with the Telerik Testing Framework

Jim Holmes — Tue, 21 May 2013 17:18:48 GMT

[NOTE: This is a guest post from Telerik’s own Phil Japikse, one of Telerik’s Senior Developer Evangelists."]

Background

User Interface testing isn’t just for quality engineers. It’s vital for developers to own part of this process as well. The days of development silos are long gone (or at least should be!) The process of throwing bits “down the line” is fraught with inefficiencies.

Developers are already adopting unit testing in record numbers, and this has led to a phenomenal increase in code quality. Why should it stop there? Developers need to also take ownership of the user interface code just like the line of business code that they develop.

Is this to say that we don’t need quality engineers? Absolutely not! What I am saying is that developers should ensure that the basic elements of the user interface are correct, and the process for testing these basic elements need to be automated just like standard unit tests are automated.

Enter the Telerik Testing Framework

Telerik’s Test Studio has an extremely powerful record/replay capability. Did you know that Test Studio’s underlying Testing Framework also provides the ability for developers to write UI tests with most of the common unit testing frameworks? In this post, I am going to show you the basics of writing functional tests with MbUnit and Gallio, leveraging the power of the Telerik Testing Framework.

The System Under Test

For this example, I am going to use a standard ASP.NET MVC application. The test is simple:

Click on the Log On link
Assert that the page changes to /Account/Logon
Find the User name text box, and enter the text “admin”
Find the Password password box, and enter the text “foo”
Find the Log On button, and click it
Verify that the resulting page contains the text “The user name or password provided is incorrect”

The Home Page

The Logon Page

The Results

Setting the Stage

There is a little bit of housework that needs to be done before this test can be developed. This isn’t much different than what you need to do to create a test project for standard unit tests, there are just a few more steps. You need to create a unit test project, select a unit test framework, add the Telerik Testing Framework references, and finally create a class that derives from the BaseTest abstract class provided by the Telerik Testing Framework.

Selecting a Unit Test Framework

The Telerik Testing Framework works with any .NET unit testing frameworks. I typically use MBUnit/Gallio in conjunction with the Telerik Testing Framework to leverage the Gallio report writer, which I will demonstrate in a future post.

Adding the Telerik Testing Framework References

There are two references that need to added to the test project. Right click on the test project, select “Add Reference…”, click “Browse…”, then navigate to “C:\Program Files (x86)\Telerik\Test Studio\Bin\” and select:

· Telerik.TestingFramework.Interop.dll

· ArtOfTest.WebAii.dll

Deriving from the Test Studio BaseTest Class

Listing 1 shows the default implementation that is needed to use the Telerik Testing Framework in unit tests. To write tests leveraging the Telerik Testing Framework, this is the minimum code that needs to be implemented in the base class that TestFixtures will inherit.

public class WebAiiUITestsBase : BaseTest

/// <summary>

/// Initialization for each test.

/// </summary>

    [SetUp]

    public void MyTestInitialize()

        // Initializes WebAii manager to be used by the test case.

        // If a WebAii configuration section exists, settings will be

        // loaded from it. Otherwise, will create a default settings

        // object with system defaults.

        // Pass in 'true' to recycle the browser between test methods

        Initialize(false);

        // If you need to override any other settings coming from the

        // config section or you don't have a config section, you can

        // comment the 'Initialize' line above and instead use the

        // following:

/*

        // This will get a new Settings object. If a configuration

        // section exists, then settings from that section will be

        // loaded

        Settings settings = GetSettings();

        // Override the settings you want. For example:

        settings.DefaultBrowser = BrowserType.FireFox;

        // Now call Initialize again with your updated settings object

        Initialize(settings);

*/

        // Place any additional initialization here

    /// <summary>

    /// Clean up after each test.

    /// </summary>

    [TearDown]

    public void MyTestCleanUp()

        // Place any additional cleanup here

        // Shuts down WebAii manager and closes all browsers currently running

        // after each test. This call is ignored if recycleBrowser is set

        this.CleanUp();

    /// <summary>

    /// Called after all tests in this class are executed.

    /// </summary>

    [FixtureTearDown]

    public void FixtureCleanup()

        // This will shut down all browsers if

        // recycleBrowser is turned on. Else

        // will do nothing.

        ShutDown();

Listing 1 – The base class for Test Fixtures

Creating your first Unit Test

Start by creating a standard Test Fixture, with two distinctive changes:

· The fixtures must be set to Single Threaded (due to limitations in how browsers and the Windows User Interface work)

· The fixtures must derive from our base class (created above)

Once those two changes are completed, unit tests can be added in the standard manner, as shown in Listing 2.

[TestFixture, ApartmentState(ApartmentState.STA)]

public class LoginUITests : WebAiiUITestsBase

    [Test]

    public void Should_Fail_Log_In_With_Bad_Username_Or_Password()

Listing 2 – Modified Test Fixture and Single Unit Test

Starting the Browser

The first step in testing a web application is launching a browser. The Telerik Testing Framework supports a number of browsers (assuming they are installed on the system running the unit test), as shown in Figure 1.

Figure 1 – The Browser choices

Navigating

Once the browser is launched through the manager, the browser instance gets assigned to the ActiveBrowser property of the BaseTest class. The ActiveBrowser exposes quite a few properties and methods, and I am only going to scratch the surface in this post.

The first thing I need to do is to navigate to the website I am testing. In my particular scenario, the url is “http://localhost:3916/”. Since all of my tests will start with this address, I add a property to my base class, as in Listing 3.

protected string _coreUrl = "http://localhost:3916/";

Listing 3 – Home Page for the site under test

My test now looks like Listing 4, which is how each of my tests begin.

[Test]

public void Should_Fail_Log_In_With_Bad_Username_Or_Password()

Manager.LaunchNewBrowser(BrowserType.InternetExplorer);

ActiveBrowser.NavigateTo(_coreUrl);

Listing 4 – Creating the Browser and Navigating to the Start Page

You might be wondering why I don’t move those two lines into a TestSetup method. While the full answer is too long and off topic for this post, I feel that TestSetup methods obfuscate the tests and become a problem leading to fragile tests.

Finding Elements on the Page

The Telerik Testing Framework supplies an extremely robust mechanism for finding elements on a page. The methods are generic, which enables Test Studio to return strongly typed elements. For example, the first item that I need to find is the HTML Anchor that has the inner text “Log On”. If the element is found, the Find process will return an HTMLAnchor class that exposes (among other elements) a Click() method. The next step is to verify that the logon page is loaded, and I use the ActiveBrowser.Url to assert that condition. This is shown in Listing 5.

Find.ByContent<HtmlAnchor>("Log On",

FindContentType.InnerText).Click();

Assert.AreEqual(_coreUrl + "Account/LogOn",

ActiveBrowser.Url);

Listing 5 – Clicking an HTMLAnchor and validating the result

The next steps are to find the text box and the password text boxes, and enter the user name and password as defined in the spec. For these, we will FindByName instead of FindByContent, since we know the form values are named. With the strong typing of the Find methods, we can then set the Text property for each of the controls. The last step is to submit the entered values by finding the HTMLInputSubmit button. This code is shown in Listing 6.

Find.ByName<HtmlInputText>("Username").Text = "admin";

Find.ByName<HtmlInputPassword>("Password").Text = "foo";

Find.ByAttributes<HtmlInputSubmit>("Value=Log On").Click();

Listing 7 – Entering and submitting values

Validating the Result

The final step in our spec is to verify that the web page shows the correct error message, and we again call on the ActiveBrowser object to validate that the page contains the text that we are looking for, as shown in Listing 7.

Assert.IsTrue(ActiveBrowser.ContainsText("The user name or password provided is incorrect"));

Listing 7 – Asserting the Text in the webpage

The completed test is shown in Listing 8

[Test]

public void Should_Fail_Log_In_With_Bad_Username_Or_Password()

Manager.LaunchNewBrowser(BrowserType.InternetExplorer);

ActiveBrowser.NavigateTo(_coreUrl);

Find.ByContent<HtmlAnchor>("Log On", FindContentType.InnerText).Click();

Assert.AreEqual(_coreUrl + "Account/LogOn", ActiveBrowser.Url);

Find.ByName<HtmlInputText>("Username").Text = "admin";

Find.ByName<HtmlInputPassword>("Password").Text = "foo";

Find.ByAttributes<HtmlInputSubmit>("Value=Log On").Click();

Assert.IsTrue(ActiveBrowser.ContainsText("The user name or password provided is incorrect"));

Listing 8 – The completed test

Summary

This post merely scratched the surface of what the Telerik Testing Framework provides to developers. Testing really needs to become a way of life for all aspects of software development, not just the quality engineers. Remember, if you don’t test it, your users will!

Next Steps!

Telerik’s Testing Framework is freely available for download from the product’s home page. You can immediately start writing functional tests for your HTML, Silverlight, or WPF applications! Want someone on call to help you with issues? Get a year of top-notch support from Telerik’s amazing support crew for only $299. (More details at the product’s home page.)

Why not go give the Telerik Testing Framework a try?

About the author

Follow @skimedic

Philip Japikse

Philip Japikse is an international speaker, a Microsoft MVP, INETA Community Champion, MCSD, CSM/ CSP, and a passionate member of the developer community, Phil has been working with .Net since the first betas, developing software for over 20 years, and heavily involved in the agile community since 2005. Phil works as a Senior Developer Evangelist for Telerik's RadControls for Windows 8 as well as the Just family of products (JustCode, JustMock, JustTrace, and JustDecompile) and co-hosts the Hallway Conversations podcast (www.hallwayconversations.com). Phil is also the Lead Director for the Cincinnati .Net User’s Group (http://www.cinnug.org). You can follow Phil on twitter via www.twitter.com/skimedic read his Telerik blog at http://blogs.telerik.com/skimedic and his personal blog at www.skimedic.com/blog.

Data-Driven Test Automation

Steven Vore — Mon, 20 May 2013 15:00:00 GMT

Greetings, fellow testers. I recently attended a workshop on Acceptance Test Driven Development, during which the presenter spoke about distilling requirements down using examples. This is a great opportunity for testers and developers to work closely with Product Owners to determine exactly what output is expected from given inputs.

There are also times when the code behind a function is particularly obtuse or for some other reason testing is best done via the application itself.

Both of these are great opportunities for data-driven automation. Data-driven test automation lets us repeat a set of test steps automatically, using a set of pre-defined values both as input and to test the application's output. While a tester could be set down in front of the keyboard and mouse, they'd always be constrained by time and so we'd need to determine a realistic subset of values to use. It would be better to let a computer run through a large number of scenarios in a fraction of the time. We can do that using Test Studio's Data Driven Testing.

Using a spreadsheet, CSV file or database, we can define as long a list of scenarios as we'd like. In this example, we've created a spreadsheet of values to test a sales tax calculation, and the Business Analyst has verified that the formulas being used are correct. She was also able to make sure we included scenarios she felt may be of particular importance, adding to the whole organization's ownership of quality.

Using Test Studio, it's a simple task to create a test for the page with one set of values, then bind that to the spreadsheet and let it run automatically. Test studio reads the data, fills in the input fields and checks the output against the expected values. In this particular scenario, we were able to check 150 different sets of values in just a few minutes.

We can quickly see where any problems are — in this case a developer was truncating a decimal value where they should have been rounding. Test studio allowed us to quickly determine the cause, get it resolved, and re-run the tests to everyone's satisfaction.

I'd be interested in hearing about other situations where data-driven testing has helped you, and invite you to drop me a note or comment below.

Peace,
Steven

About the Author

Steven Vore

Steven Vore is an Evangelist of Telerik's Test Studio. He has worked in software support and testing for the better part of two decades, and enjoys exploring ways to make software easier to use. He is a fan of movies and music, and can often be found on Twitter as @StevenJV.

Test Studio Web Portal: The Time Has Come

Anthony Rinaldi — Fri, 17 May 2013 20:41:23 GMT

We recently released Test Studio for iOS Version 2.0, and with it a new companion Web Portal. We issued a three month extended trial for the Web Portal as a thank you to our early adopters.

Subscription Options

That extended trial came to an end this week. To continue using the Web Portal, head over to our pricing page for all the subscription details. The premium features can be purchased together or independently, and in custom quantities. We went with the a la carte model to give you more flexibility. You can add exactly what and how much you need, without paying for something you don't need and won't use.

New Trial Format

If you didn't sign up early enough to take advantage of our extended trial, don't worry! We've switched to a standard 30 day trial format. Log in to the Web Portal today with your Telerik.com account to start submitting feedback, crash reports, and syncing tests and results. See our user's guide to learn more.

About the Author

Anthony Rinaldi

Anthony Rinaldi is the Product Manager of Telerik's Test Studio for iOS. He combines his experience in test automation and quality assurance with his passion for Apple mobile devices and the iOS platform. He is an avid CrossFitter, soccer player, and music fan.

Cooking With Web Automation Webinar Series

Jim Holmes — Wed, 15 May 2013 16:54:37 GMT

Good web automation isn’t about best practices (there aren’t any!), but instead using much more of a cookbook approach: Have a problem? Find a recipe that helps you cook up a solution. The recipe you might need may not be a huge flambé, but the idea’s still a good one.

To help you with this we’ve decided to start a monthly webinar series showing you how to work through specific issues in web automation: Cooking With Web Automation. Your friendly Test Studio team will be co-hosting these webinars with various automation, testing, and/or developer gurus.

We’ll focus these short 30 minute webinars on working with one specific problem, and show you a number of ways to solve it. You’ll also see recipes based on a broad number of tools, not just Test Studio. This will help you understand automation in a critical, broader context.

Our first installment will be JQuery UI Menus.

We have reached the point where tricks and patterns for proper element discovery, synchronization and code organization are starting to repeat themselves. But what we don't have are specific 'recipes' for dealing with the more complex automation challenges that people encounter each day. Join Adam Goucher [Element 34] and Jim Holmes [Telerik] for a 30 minute webinar on 21 June at 11:30 US Eastern as they wrestle JQuery UI's Menu widget.

What are you waiting for? Go register now!

Do you have particular problems you’d like us to cook up a session for?

About the author

Jim Holmes

Jim Holmes has around 25 years IT experience. He's a blogger and is the Director of Engineering for Telerik’s Test Studio, an awesome set of tools to help teams deliver better software. He is co-author of "Windows Developer Power Tools" and Chief Cat Herder of the CodeMash Conference. Find him as @aJimHolmes on Twitter.

Interested in chatting with Jim at a conference? Check out his speaking schedule!

More “That’s Neat!” Episodes Posted

Jim Holmes — Tue, 14 May 2013 20:13:10 GMT

You may have caught some of the earlier “That’s Neat!” episodes I’ve posted over the last year or so. I’ve just posted a number of new ones, and have gathered all of them into one series suitably titled, wait for it… “That’s Neat.”

I hope you enjoy these! They’re always fun to make. We’ll be adding more in the future.

Do you have some favorite feature of Test Studio you’d like to see in a “That’s Neat!” episode?

About the author

Jim Holmes

Interested in chatting with Jim at a conference? Check out his speaking schedule!

New Video: Guide to Success Part II

Jim Holmes — Tue, 14 May 2013 18:43:09 GMT

OK, so it turns out I got badly distracted after my Guide to Success Part I and never actually finished Part II. Whoops. Consider this egregious error rectified now!

In this episode you’ll learn more about the Element Repository, Reporting, Performance Testing, Manual Tests, and some next steps you can take on your own.

I hope you find the video helpful!

About the author

Jim Holmes

Interested in chatting with Jim at a conference? Check out his speaking schedule!

Sample Code & Slides from StarEast 2013 Talk

Jim Holmes — Tue, 14 May 2013 18:16:01 GMT

I gave a talk on Four Tips for Web Automation at StarEast 2013 this April. I’ve posted up my slides on SpeakerDeck

You can also find the demo code at my GitHub repository.

Were you at the talk? Did you find it useful?

About the author

Jim Holmes

Interested in chatting with Jim at a conference? Check out his speaking schedule!

Telerik Test Summit 2013 Wrapup

Steven Vore — Thu, 09 May 2013 17:00:00 GMT

Greetings, fellow testers. Last week, we hosted a number of thought leaders in the testing community as part of the 2nd annual Telerik Testing Summit (Twitter: #TelSum) in Austin, Texas. The event is a free-form peer conference on software development — of which testing is an important part — its current state and possible avenues of improvement. The agenda was developed on the spot and adjusted throughout the weekend, with an emphasis on flexibility. A few tools and technologies were mentioned, but this was very much a broad discussion of people and how they relate to each other, of ideas and suggestions.

I was fortunate enough to attend this year; also from Telerik were Jim Holmes plus Holly Bertoncini, our event organizer. We were joined by Paul Carvalho, Trish Khoo, Adam Goucher, AlanPage, Matt Brandt, Selena Delesie, Matt Barcomb, Jeff Morgan, Marlena Compton, and Chris McMahon. It was great to meet these folks in person, get to know them, and hear their thoughts and insights.

As we gathered on Friday, we papered the walls with extra-large "stickies" and started in with suggestions for topics and deciding how we'd progress. We had many hours of topic-based discussion on Friday.

Many of the participants will be posting their thoughts on their own blogs; some have already begun to do so, and I encourage you to go check them out. I'll be posting some of my observations and thoughts over the next week or so, but I thought I'd start with a list of our topics:

Testers' Image, Testing as a Career
Dest Design
Pairing with Developers
the Future of Work
Which Metrics Don't Suck?
Community Testing Bootstrapping

After a few lightning talks and some small-group discussions (including Jeff huddled with several people talking about Cucumber and how/when to use it effectively) on Saturday morning, we shared book recommendations, worked on a Testing project for Wikipedia, and spent some time closing out to summarize and creating action items. We didn't want our discussions to end as we departed; we all walked out with tasks for improving not only our own organizations but Testing as a whole.

Peace,
Steven

About the Author

Steven Vore

Introduction to Manual Testing using Test Studio

Steven Vore — Sun, 05 May 2013 18:00:00 GMT

Greetings, fellow testers. I'm excited to be joining the Telerik family, and I'll be sharing tips and tricks, ideas and suggestions with you here. I plan on providing a good bit of intro information for our new users as well as more in-depth articles for those of you who have already invested a good bit of time in Test Studio.

UI Automation is what brings most of us to Test Studio in the first place, but I want to start here by pointing out a component that's easily overlooked - Test Studio's support of manual testing. As Jim often says, there are plenty of tests that should not be automated. Checking element alignment on the page, for example, or that the right icon is being displayed — these sort of tests are much more quickly and easily done by the human eye.

Perhaps more imporantly for new users: Using Test Studio to organize and execute your existing manual tests is a great way to get started, giving quick visibility into the work you're already doing.

Most of us have used spreadsheets to keep track of tests, and we know the pain of keeping them updated, tracking which tests have passed and when, and reporting on them. Spreadsheets are great, but this just isn't a task for which they were built — especially when used by multiple people.

Enter Test Studio's manual testing management. Import your tests into Test Studio and forget about spreadsheets; test case editing, management and tracking become a snap. Your team can see which tests have been done and which haven't, and can easily note success or failures along the way.

Now, as you're going through your tests, instead of wondering which cases passed or failed recently or which team members have up-to-date spreadsheets, you can be thinking more about which tests to automate first. Manual testing is often an overlooked feature of Test Studio. Give it a try and let me know how it works for you.

Peace,
Steven

About the Author

Steven Vore

Test Studio for iOS 2.0.1 Is Live!

Anthony Rinaldi — Thu, 18 Apr 2013 16:02:59 GMT

As promised in the preview post, some great new features are available today in version 2.0.1:

Jenkins CI support
Expanded TSReport support: Xamarin.iOS and Cordova
Bug fixes

To get started, update Test Studio for iOS from the App Store, download the latest file bundle from Telerik.com, and update the testing extensions in your native app.

Stay Tuned

We're improving the Feedback image editing experience for version 2.1. Stay tuned here for previews and a release date.

About the Author

Anthony Rinaldi

Handling Asynchronous Delays in Test Studio for iOS

Anthony Rinaldi — Fri, 12 Apr 2013 21:03:23 GMT

Asynchronous delays are one of the biggest automation challenges you'll encounter. Jim Holmes has a great discussion on this in his blog post on the Windows desktop version of Test Studio. It's definitely worth a read, but here are some highlights just in case:

It's hard to determine what to delay for your test's execution.
Do not rely on fixed execution delays.
Isolate the condition that should be met for test execution to continue.
Create an explicit wait for that condition.

But what about the mobile space? How do we account for asynchronous delays in our mobile apps or web pages? Test Studio for iOS has you covered! Read on for more.

Example

To simulate a call back to the server, I made a slight change to our demo application. Normally, tapping a button on the UIButton screen immediately changes a UILabel at the bottom of the screen. Instead, I've wired Button 1 to not update the label until five seconds after the tap.

The Test

Let's create a basic test against this button and its functionality. I'll navigate to the UIButton screen, tap Button 1, and verify the text of the UILabel. Here's what that test looks like:

Let's execute the test. It should pass, right?

Wrong. The text verification at step three failed. But why?

The Problem

So what happened? Let's drill into the failed step to find out. Tap step three under the Step Results section. The failure summary shows that the UILabel's text did not update in time:

Tap Go to Step at the bottom of the screen. Next tap the Operation cell:

We see that the default timeout for a Wait Verification is three seconds. Since our label takes five seconds to update, the test fails.

The Fix

It's as easy as increasing the timeout to adequately cover the condition. In this case the label takes five seconds to update, so I'll increase the timeout to six seconds:

If your condition is inconsistent, consider bumping up the timeout to cover the longest possible scenario. And remember, this timeout is not fixed. The Wait step continuously checks for its condition to be met up to the timeout. If the condition is met before the timeout, the step immediately passes and the test continues. If the condition is never met, the step fails after waiting the full length of the timeout.

Let's execute again. The test should pass:

The Takeaway

Test Studio for iOS makes it easy to handle asynchronous delays with its standard Verification step type. In fact, our Verification step is set to be a Wait by default. You just may need to increase its timeout setting to accommodate your scenario.

About the Author

Anthony Rinaldi

Challenge your RadGrid for Asp.Net AJAX

Pavel Pankov — Thu, 11 Apr 2013 12:48:20 GMT

Or How to Ensure It Does what you want

Automating a Grid component can be a challenge and not because it’s hard. It has it subtleties, but it’s not the most complicated thing in the trade, by far. With Telerik Test Studio you can test RadGrid for Asp.Net AJAX with ease and thoroughness. In this Blog post I’ll show a few tips that can make this not only possible, but a child’s play for everyone.

Telerik’s software testing solution Test Studio comes with built-in translators for all of its component suites. This means that you get convenient verifications when you hover over specific elements like the Grid’s column headers. In the attached picture you can see a sorting verification.

The same applies for the actions as well – clicking the numbers in the pager will record as a RadGrid specific action for navigating to a given page. Telerik Test Studio provides verifications which validate the pager mode and the selected page. We can also go as far as drag-drop grouping actions and verifications for the currently grouped columns. It’s all there!

Now let’s step back a bit and look at the bigger picture. A good Grid is a composite component. RadGrid is no different in this regard. It contains text boxes, date pickers, combo boxes, HTML editors and what not. When you are automating this control, you actually need all the nested ones to be supported as well. In the upcoming blog posts we’ll be focusing on those. Stay tuned for more details on how to automate your RadEditor, RadComboBox, RadTreeView and more!

But for now I’ll leave you to explore how versatile automating with Test Studio can be!

About the author

Pavel Pankov

Pavel Pankov is a QA Lead at Telerik’s Testing Tools division. He joined the company back in 2007. Through the years he was responsible for part of the Translators and Wrappers for the ASP.NET AJAX controls, and has been actively involved in the adoption and development of Telerik’s software testing product. Now he focuses his attention on the improvement and continuous success of Test Studio. In his spare time he likes to swim and ride his mountain bike.

Fiddler Gets a New Website Backed with Community Resources

Christopher Eyhorn — Thu, 11 Apr 2013 08:46:37 GMT

A few months back our announcement of Fiddler joining the Telerik family received huge response in the community. As part of our efforts, we made it a point to ask you for advice and feedback on next steps. Much like the news itself, this request was well received and funneled back to us amazing, interesting and very useful feedback and advice. The impact of the community has helped us stay focused and devoted to the thousands of Fiddler users, and deliver on our promise to provide better user experience, support resources and additional product features in the months to follow.

Fast forward 8 months - we made the first step together in November – you helped us choose Fiddler’s new logo. Now we are excited to share with you the first phase of the Fiddler’s website revamp! The main goal -- to make Fiddler’s website a bit easier to navigate and help you quickly find what you need.

We are now happy to offer the Fiddler community rich, up-to-date and publicly available documentation consisting of more than 100 product topics. Naturally, we’ll continue adding fresh content, keeping this a living and breathing document, always in sync with the upcoming product developments. We’ll be also adding new short videos to the Telerik Fiddler YouTube playlist to complement the currently available Fiddler resources.

In the next phase of the website redesign will be featuring integrated and consistent Forums experience.

We see today’s news as a next step in our journey to give back to the Fiddler community. As per your request, we will continue working on a major product UI facelift as well as enhanced product functionality to ensure all of your feedback is not only responded to, but acted upon. Please stay tuned for additional updates.

Christopher Eyhorn
EVP Testing Tools
Twitter: @ChrisEyhorn

Working With Visual Studio: A Familiar Environment

Jim Holmes — Mon, 08 Apr 2013 11:47:06 GMT

As I mentioned in my last post's closing, Test Studio's plugin for Visual Studio lets developers and coding testers work right in an environment they’re familiar and comfortable with. You’ve undoubtedly customized Visual Studio to fit your particular needs: display settings, window behavior and layout, and any number of other plugins and productivity tools such as Telerik’s JustCode.

Working with Test Studio inside of Visual Studio leaves you the ability to pull in other tools easily through NuGet. Do you prefer using NUnit or MbUnit for their powerful Assert and fluent interfaces? Go right ahead! (Note that you can also use outside assemblies easily straight from within Test Studio Standalone, too. You won’t be handicapping other team members using that interface!)

Here’s another example of using a test oracle for validation, this time via NUnit. The example below shows evaluating a downloaded file against a baseline or “truth” file. NUnit’s “Within” clause from its fluent API makes range comparisons simple.

Source control integration for your test suites is a snap from within Visual Studio too. Use the exact same approach you do with your current toolset. Test Studio, ether the Standalone or Visual Studio plugin versions, play nicely with all source control tooling, so you won’t have to alter your habits, teams’ workflows, or worse yet, change your source control system.

Test Studio and Visual Studio: Give it a Try!

Have you avoided Test Studio because you thought a commercial tool would limit your ability to write code to perform customized tasks in your automated suite? Hopefully these last four posts have helped shine some light on that misconception! Why not go grab a trial of Test Studio and give it a try?

More blog posts on the topic of Developer Testing: Working with Visual Studio: Write Code Where Needed & Developers and Functional Testing

About the author

Jim Holmes

Jim Holmes is the Director of Engineering for Test Studio. He has around 25 years IT experience. He's a blogger and the co-author of "Windows Developer Power Tools" and Chief Cat Herder of the CodeMash Conference. Find him as @aJimHolmes on Twitter.

CodeProject

TSReport Examples

Anthony Rinaldi — Fri, 05 Apr 2013 21:19:26 GMT

TSReport is a great new feature of Test Studio for iOS 2.0. It's an iOS reporting library that provides services and tools for reporting feedback and crashes. This library can go into the release version of your application that you submit to the App Store. End-users can then submit feedback and crash reports directly through the app, without going through the separate Test Studio app. You view their submissions in the accompanying Test Studio Web Portal. Here is how to set up TSReport in your native UIKit application. And remember, TSReport support for Xamarin.iOS and Cordova/PhoneGap apps is coming soon.

Example 1 – Button

After setup, it's time for implementation. A simple example is to add a button that calls our default feedback view controller. Place this button on one or more screens in your application where you'd like to elicit feedback. See here for a walk-through.

Example 2 – Shake

If your app has several views or you don't have screen space to spare, you'll probably want a more sophisticated option. Inspired by the awesome feature in the Google Maps app, we created a "Shake for Feedback" example. See here for a walk-through. This is a really handy yet subtle way to load the feedback screen from anywhere in your app. This can theoretically be applied to other gestures like swipe, pinch, and double-tap.

Go Custom

Our default feedback view controller gives you a ready-made, working solution out-of-the-box. But what if you want to customize the feedback submission process to match the look and feel of your application? We've got you covered! Use our provided methods to wire up any view you design. See the Custom Feedback Integration section here for more information. Also, don't forget about the Additional Methods available to take a screenshot and send/purge queued items.

Call to Action

Are you using TSReport in a unique way? Do you have ideas on how to make this feature better? We'd love to hear about them all! Post your examples, ideas, and suggestions to comments. Get creative, people!