Entries tagged with testing - Channel 9

Wolfgang Grieskamp and Keith Stobie: Spec Explorer - An Overview

Charles — Tue, 27 Oct 2009 04:46:00 GMT

Spec Explorer is a visual tool for modeling software behavior and generating test suites from those models. It has just been released on DevLabs.

Here, architects Wolfgang Grieskamp and Keith Stobie join us to discuss the thinking behind Spec Explorer. You can see Spec Explorer in action here. What problems does the model-based approach to testing solve? How is Spec Explorer related to contractual programming (Spec#, .NET Contracts, etc)? What's the holy grail of this approach to advanced and efficient testing? Everything has a rich history and Spec Explorer is no exception. What is the history here? What's next?

Spec Explorer Blog: http://blogs.msdn.com/SpecExplorer

SpecExplorer: Model-Based Testing made practicable

Peli de Halleux — Tue, 27 Oct 2009 04:45:00 GMT

Keith Stobie, Wolfgang Grieskamp, and Nico Kicillof gave a presentation on the new version of Spec Explorer 2010 for Visual Studio. Spec Explorer is a visual tool for modeling software behavior and generating test suites from those models. Spec Explorer’s approach to model-based testing has been shown to greatly enhance productivity of test case creation, to ensure predictability of requirement coverage, and to support lifecycle management and software updates. Models are typically written in C# and controlled by a configuration language which allows to express scenarios and test purposes. Microsoft itself chose Spec Explorer as a cornerstone of the effort to validate open protocol documentation, developing more than 200 test suites validating over 40,000 requirements for networking protocols in a production environment.

Pruebas Unitarias (Unit Testing) con Visual Studio

Channel9Spain — Fri, 23 Oct 2009 21:23:00 GMT

Aurelio Porras, especialista en Soluciones de Desarrollo en Microsoft Ibérica, nos presenta un nuevo Webcast sobre Visual Studio 2008. En este video nos contará qué son las pruebas unitarias y cómo podemos hacerlas desde Visual Studio 2008 en cada una de sus versiones.

- Enlaces
Pruebas Unitarias en Visual Studio 2008 -http://msdn.microsoft.com/en-us/library/ms182515.aspx

Pruebas Unitarias en Visual Studio 2010 – http://msdn.microsoft.com/en-us/library/dd264975(VS.100).aspx

ARCast.TV - How to Improve Testability with a Modular Architecture

Bob Familiar — Mon, 12 Oct 2009 16:26:00 GMT

Mario Cardinal and Aaron Kowall discuss how to easily test in an autonomous way an application conceived with modular abstractions such as the "layer". Mario and Aaron discuss how to partition the concerns of the application into layers and best practices regarding application architecture and modularity.

Windows 7 Compatiblity Screencast: Effective Windows 7 Testumgebung aufbauen

codefest — Fri, 21 Aug 2009 13:54:00 GMT

Effective W7 Testenvironment

Patrice Godefroid - Automated Whitebox Fuzz Testing with SAGE

Peli de Halleux — Tue, 14 Jul 2009 18:29:00 GMT

Patrice Godefroid gives an overview of Automated Whitebox Fuzz Testing, a powerful testing technique applied at Microsoft through a tool called SAGE. Listen how he is working with the SAGE team to 'eradicate all buffer overrun bugs' in Windows...

Read more in this paper or this slide deck.

The Research in Software Engineering team (RiSE) coordinates Microsoft's research in Software Engineering in Redmond, USA.

How Attachmate Earned Windows 7 Software Logo

bruceky — Tue, 07 Jul 2009 00:46:00 GMT

Attachmate was among the very first to earn the Compatible with Windows 7 software logo. In this video, Product Marketing Manager Kris Lall and Test Lead Chinh Vu talks with me about the whole process.

Kris tells why the logo is important to Attachmate and the customer benefits. Chinh explains the process, how it is different from other logo tests, and what steps he took to get the logo.

For more information about the products Attachmate has had logo tested, see Attachmate Information Center for Windows 7.

p&p Acceptance Testing guide Beta 2 is now available

ajoy krishnamoorthy — Thu, 02 Jul 2009 17:22:00 GMT

patterns & practices has produced few guides related to testing (including performance testing, security testing of web apps, and testing of .NET application blocks). However, we have heard a lot of requests from our customers for guidance on testing and test strategy in general. Based on the feedback, we started a project last year to build guidance on acceptance testing.

What is acceptance testing?

Working definitions for a number of terms are available in our Draft Glossary. The current definition that is framing our work and discussions is:

Acceptance Testing: Planned evaluation of a system by customers/customer proxies to assess to what degree it satisfies their expectations.

Download Beta 2 version of this guide and provide your feedback.

Happy Reading!

Sebastian Burckhardt - Data Race Detection with CHESS

Peli de Halleux — Fri, 12 Jun 2009 18:31:00 GMT

Sebastian Burckhardt gives a short tutorial of some of the new features of CHESS: data race detection and ChessBoard. CHESS is a concurrency testing tool takes a concurrent unit test and executes it with different thread schedules. Sebastian explains us how CHESS can detect data races, a very subtle kind of concurrency bug. You'll also learn how to drill into concurrency issues using the ChessBoard, a little application designed to drill and investigate concurrent tests.

CHESS home page: http://research.microsoft.com/en-us/projects/chess/
CHESS forums: http://social.msdn.microsoft.com/Forums/en-us/chess/threads/

The Research in Software Engineering team (RiSE) coordinates Microsoft's research in Software Engineering in Redmond, USA.

Extreme ASP.NET Makeover: Testing - Acceptance Tests

Howard Dierking — Fri, 05 Jun 2009 06:58:00 GMT

Acceptance Tests

Acceptance tests using WatiN are simply longer versions of smoke tests. The following shows an acceptance test to verify that we can create a new page in our wiki.

[Test]
public void CanCreateNewWikiPage() {
    string pageName = string.Format("TestPageName-{0}", Guid.NewGuid());
    const string pageTitle = "TestPageTitle";
    using(var browser = new IE()) {
        browser.GoTo(PageUrl.Default);
        browser.LoginAsAdmin();
        browser.CreateWikiPage(pageName, pageTitle);
        Assert.That(browser.WikiPageTitle(), Is.EqualTo(pageTitle));
        Assert.That(browser.Url, Text.Contains(pageName));
    }
}

I created an extension method BrowserExtensions.CreateWikiPage to encapsulate the logic of creating a new page.

public static void CreateWikiPage(this Browser browser, string pageName, string pageTitle) {
    browser.Link(Find.ByTitle("Create a new Page")).Click();
    browser.TextField(Find.ByTitle("Type here the name of the page")).TypeText(pageName);
    browser.TextField(Find.ByTitle("Type here the title of the page")).TypeText(pageTitle);
    browser.Button(Find.ByValue("Save")).Click();
}

Another extension method simplifies finding a wiki page's title; not the contents of the <title/> tag, but the contents of the <h1 class="pagetitle"/> tag.

public static string WikiPageTitle(this Browser browser) {
    return browser.ElementWithTag("h1", Find.ByClass("pagetitle")).Text.Trim();
}

As we write more acceptance tests, the BrowserExtensions class may become unwieldy in size. If this happens, I can easily refactor the code into BrowserLookupExtensions (for finding information in the page) and BrowserScriptingExtensions (for manipulating the page). I could separate extension methods by public and admin, particular function, or any other means to make the code more tractable.

Read the full article at http://msdn.microsoft.com/en-us/magazine/dd744751.aspx

Extreme ASP.NET Makeover: Testing - Eliminating Repetition from Tests

Howard Dierking — Fri, 05 Jun 2009 06:58:00 GMT

Eliminating Repetition from Tests

You'll notice a lot of potential for repetition in the CanLogIntoSite test.

· Every WatiN test will have a URL starting with http://localhost:9999.

· Many tests will require the user to be logged in.

· Multiple tests might want to verify the currently logged in user.

As you can imagine, we'll see similar repetition as we write more tests. Let's apply the principle of Don't Repeat Yourself (DRY) to our WatiN test.

Let's apply the principle of Don't Repeat Yourself (DRY) to our WatiN test.

[Test]
public void CanLogIntoSite() {
    using(var browser = new IE()) {
        browser.GoTo(PageUrl.Default);
        browser.LoginAsAdmin();
        Assert.That(browser.IsLoggedInAs("admin"));
    }
}

I've created a PageUrl class that is simply a Uri list for pages in the site. I've also created some extension methods on WatiN's Browser class to script out common actions.

public static void LoginAsAdmin(this Browser browser) {
    if(browser.IsLoggedInAs("admin")) {
        return;
    }
    browser.Link(Find.ByTitle("Login")).Click();
    browser.TextField(Find.ByTitle("Type here your Username")).TypeText("admin");
    browser.TextField(Find.ByTitle("Type here your Password")).TypeText("password");
    browser.Button(Find.ByValue("Login")).Click();
}

public static bool IsLoggedInAs(this Browser browser, string expectedUsername) {
    var username = browser.Link(Find.ByTitle(title => title == "Go to your Profile" || 
        title == "Select your language")).Text;
    return username == expectedUsername;
}

Not only am I encouraging re-use with my extension methods, I can more readily ascertain what my CanLogIntoSite test does by using concise, meaningful names for the helper methods. I have also eased my maintenance burden because when I do add IDs to the username/password textboxes and correct the grammar, I have minimized the number of changes I will need to fix my tests.

Read the full article at http://msdn.microsoft.com/en-us/magazine/dd744751.aspx

Extreme ASP.NET Makeover: Testing - Using WatiN

Howard Dierking — Fri, 05 Jun 2009 06:57:00 GMT

Using WatiN to Test a Local Web site

Now that we have successfully run a simple WatiN test against a remote Web site, we turn our attention to using WatiN to test ScrewTurn Wiki. We won't want to deploy ScrewTurn Wiki to a server every time we want to run our acceptance test suite using WatiN. Instead, we will use the ASP.NET Development Server (WebDev.WebServer.exe), which is better known by its code name "Cassini." It is installed with .NET Framework 2.0 and above in C:\Windows\Microsoft.NET\Framework\v2.0.50727\. Another option would be to use a local IIS instance, but the ASP.NET Development Server has the nice feature that it can be started and/or stopped by a normal user.

We want to start ASP.NET Development Server before any WatiN tests are run and stop it once testing is complete. Most test frameworks have a method for specifying code to run before and after any tests. In NUnit 2.4.8, we use the SetUpFixture attribute on a class to mark it as containing setup/teardown code for all tests in the same namespace, as shown below.

using System.Configuration;
using NUnit.Framework;

namespace ScrewTurn.Wiki.Tests {
    [SetUpFixture]
    public class WebServerRunner {
        private WebServer webServer;

        [SetUp]
        public void StartWebServer() {
            var absolutePathToWebsite = ConfigurationManager.AppSettings["absolutePathToWebsite"];
            webServer = new WebServer(absolutePathToWebsite, 9999);
            webServer.Start();
        }

        [TearDown]
        public void StopWebServer() {
            webServer.Stop();
            webServer = null;
        }
    }
}

The WebServer class is a helper class that encapsulates the ASP.NET Development Server. It needs the physical path to the compiled Web site and a fixed port. We need a fixed port, such as 9999, so that we can direct WatiN to browse to http://localhost:9999 in our tests.

ASP.NET Development Server on Windows Vista and Later

The ASP.NET Development Server only listens for requests on IPv4, not IPv6. If you are running Windows Vista or Windows Server 2008, requests for "localhost" will resolve to the IPv6 address of ::1 by default rather than the IPv4 address of 127.0.0.1 and the WatiN tests will fail. To resolve this issue, comment out the IPv6 localhost address in your C:\Windows\System32\drivers\etc\hosts file. This is the line with "::1 localhost".

The Start method for WebServer formats the command line arguments for WebDev.WebServer.exe and launches it using a System.Diagnostics.Process object:

public void Start() {
    webServerProcess = new Process();
    const string webDevServerPath = @"c:\Windows\Microsoft.NET\Framework\v2.0.50727\WebDev.WebServer.exe"";
    string arguments = string.Format("/port:{0} /path:\"{1}\" /vpath:{2}", port, physicalPath, virtualDirectory);
    webServerProcess.StartInfo = new ProcessStartInfo(webDevServerPath, arguments);
    webServerProcess.Start();
}

At the end of the test run, the Stop method terminates the Cassini process:

public void Stop() {
    if(webServerProcess == null) {
        throw new InvalidOperationException("Start() must be called before Stop()");
    }
    webServerProcess.Kill();
}

NOTE: You might receive a strange error message from the ASP.NET Development Server stating that "The directory '<PATH> /vpath:' does not exist", as we see below. This is a bug in the ASP.NET Development Server which causes it to fail if your physical path has a trailing \. To bypass this bug, simply remove the trailing slash in your configuration file or code defensively using physicalPath.TrimEnd(\\) on any physical path intended for the ASP.NET Development Server as I did in the constructor for ScrewTurn.Wiki.Tests.WebServer.

Smoke Tests

Our goal in writing acceptance tests is to ensure that end user functionality continues to work as expected, as we add features or refactor existing code for better maintainability. Before getting into complex workflows, we will write some simple smoke tests using WatiN to ensure that ScrewTurn Wiki's basic functionality is working. (A smoke test is a preliminary test designed to show simple and obvious failures, such as an error in the web.config file resulting in the site being inaccessible.) Our smoke tests include the actions of:

· Browsing to the main page

· Logging into the site

· Browsing the admin pages redirects to the login page

· Accessing a nonexistent page redirects to a page not found information page

Note that you don't have to think of everything immediately, but can gradually add tests as you build your test suite.

We'll start out with testing whether a user can log into the site as an administrator. (By default, ScrewTurn Wiki's administrative account is admin/password.) The WatiN script should be fairly self-explanatory. You are finding page elements, such as the Login link, and then performing actions, such as clicking the Login link via its Click method, as shown here.

[Test]
public void CanLogIntoSite() {
    using(var browser = new IE()) {
        browser.GoTo("http://localhost:9999");
        browser.Link(Find.ByTitle("Login")).Click();
        browser.TextField(Find.ByTitle("Type here your Username")).TypeText("admin");
        browser.TextField(Find.ByTitle("Type here your Password")).TypeText("password");
        browser.Button(Find.ByValue("Login")).Click();
        var username = browser.Link(Find.ByTitle("Go to your Profile")).Text;
        Assert.That(username == "admin");
    }
}

The only slightly confusing part might be how to find the page elements. (e.g., How did I know to find the username textbox by looking for its title, "Type here your Username"?) You need your browser of choice and a tool or two, such as Internet Explorer and the Internet Explorer Developer Toolbar or Firefox and Firebug/Web Developer Toolbar.

Finding by selecting an element's title isn't recommended because it is more likely to change. For example, the text really should say "Type your username here." If we correct the grammar, however, we break the test. I wanted to create the smoke tests before modifying the site, which is why I left the text as it is. A better option for identifying page elements is by ID. (You can find elements by ID using Find.ById("id") instead of Find.ByTitle("title"). The Find class contains a wide variety of static methods for simplifying the location of page elements.) So while WatiN can automate any site, you can make your tests more robust in the face of change (and language translations) by providing IDs for elements of interest.

Read the full article at http://msdn.microsoft.com/en-us/magazine/dd744751.aspx

Extreme ASP.NET Makeover: Testing - Of Tightropes and Tests

Howard Dierking — Fri, 05 Jun 2009 06:57:00 GMT

Of Tightropes and Tests

Applying a strong suite of automated tests provides a codebase with a safety net. Developers can modify code protected by tests in relative safety. Method implementations can be changed, class hierarchies refactored, and code improved in a myriad of ways. Automated tests can be run on the code at any time to verify that existing functionality is not broken. Existing automated tests act to prevent regressions from entering the codebase. (A regression is a feature that previously worked, but does not anymore.)

Now why would a development team want to modify working code? There are many reasons:

A bug needs to be fixed and you want to fix it without breaking other functionality.
You think of a better or more efficient method of implementing a feature.
You want to pay down some technical debt accrued by the team.

(Technical debt is a metaphor created by Ward Cunningham to describe the gradual accumulation of friction in a codebase due to quick-and-dirty programming. As technical debt builds, the difficulty in working with a codebase increases. You can reduce this debt by refactoring the code to eliminate duplication, increase cohesion, decrease coupling, etc. Your chances of refactoring code safely increases, thereby reducing technical debt, if you have a good automated test suite acting as a safety net.)

Just like a safety net used when walking tightropes, a suite of automated tests is only as good as its coverage. Having a safety net isn't much use if you fall outside of the net’s perimeter or if the holes in the net are big enough to let you fall through. The same holds true for automated tests. If you are modifying code that isn't tested, you are walking a tightrope without a safety net.

Testing Landscape in an ASP.NET World

We will focus on developer-oriented testing, including unit, integration, and acceptance testing. These terms are often confused such that most "unit tests" are actually integration tests. Developers think that they're writing unit tests because they're using a unit testing framework. What we, as developers, call "unit testing frameworks" are in reality "testing frameworks" that can be used to write a wide variety of test types.

If most developers are actually doing integration testing, what is unit testing? Unit testing involves testing a single component, which in object-oriented terms is a class. With integration testing, we are testing a set of components working together.

There are a wide variety of testing frameworks available for the Microsoft .NET Framework. The most commonly used ones are NUnit, MbUnit, xUnit, and MSTest. All are .NET ports of JUnit, the original Java testing framework. Actually the original unit testing framework was SUnit, written by Kent Beck, for Smalltalk, but wasn't widely distributed. Beck went on to co-write JUnit with Erich Gamma and JUnit did gain widespread acceptance.

ScrewTurn Wiki already uses NUnit for unit and integration testing and we will continue to use NUnit throughout the series. The unit and integration tests apply to business, data access, workflow, and similar logic. They do not interact with the HTML and JavaScript of a Web page. These tests provide us with a safety net when working with the core application code. We are going to examine ScrewTurn Wiki's unit and integration tests in detail in a future article when we talk about refactoring the core application code. In the next few articles, we will be updating and improving ScrewTurn Wiki's HTML, CSS, and JavaScript. We need a safety net here too and so we turn our focus in this article to automated acceptance tests around the Web user interface.

Automated Acceptance Testing

Acceptance testing is black-box, end-to-end testing of a system to ensure that it meets the needs of the end user. Acceptance tests are often typified by long, verbose Word documents with step-by-step manual instructions, which are performed and verified by the QA department or end users. Here is a simple manual acceptance test:

Verify Administrative Portal Requires Admin Credentials

Browse to the main page at http://server/Default.aspx.
If currently logged in, click Logout.
Verify that you are accessing the site as a guest. ("Welcome guest" should be displayed in the top right.)
Browse to http://server/Admin.aspx.
Verify that you are re-directed to http://server/Login.aspx and prompted for credentials.

A typical system will have dozens to hundreds of these tests. Manual testing is repetitive, monotonous, time-consuming, and error-prone. The immediate question that should jump to mind is, "How difficult is it to automate these acceptance tests?" As it turns out, it is a lot easier than you might otherwise think.

Introducing WatiN

WatiN is a Web application testing framework written in C#. It is an acronym for Web Application Testing in .NET and was inspired by WatiR - Web Application Testing in Ruby. To use WatiN, you simply reference WatiN.Core in your test project and start writing test code. It integrates with all of the major .NET testing frameworks. Here is some NUnit code using WatiN:

[Test]
public void CanBrowseToMicrosoft() {
    using(var browser = new IE()) {
        browser.GoTo("http://www.microsoft.com/");
        Assert.AreEqual("Microsoft Corporation", browser.Title);
    }
}

In the code above, IE is a class defined in WatiN.Core. When an instance of IE is created, an actual instance of Internet Explorer is launched. WatiN automates the browser, instructing it to go to a particular URL and retrieve the title of the resultant page. WatiN can also click on buttons and links, fill in form fields, hover over elements, and just about anything else a real user can do. Since WatiN is automating a real browser, you have real JavaScript and Asynchronous JavaScript + XML (AJAX) support. With WatiN, you can automate complex user interactions that traverse multiple pages, such as adding or editing a page on a wiki, buying an item (including a multi-step checkout) on an e-commerce site, or completing a multi-page survey on a polling site. Rather than write isolated simple tests, you can actually automate business-relevant workflows. Since you're running the acceptance tests through a testing framework, you can create a clean database and/or site with default content before every test run, which maximizes your ability to create a reproducible set of acceptance tests that can be run on demand without user interaction.

In addition to automating Internet Explorer, WatiN 2.0 (which is currently in beta) can automate Mozilla Firefox v2/v3 and has very preliminary support for Google Chrome. Eventually you will be able to do some cross-browser testing with WatiN, though not cross-platform because WatiN directly automates the browser, which must be running on Windows. We will be focusing on Internet Explorer since WatiN's support for that browser is the most mature.

Setting Up WatiN

Wouldn't it be wonderful if software just worked right out of the box every time? WatiN is a bit trickier than most. In getting WatiN running on your system, you have two hurdles to overcome. WatiN is interacting with Internet Explorer through a COM automation API. WatiN is able to hide almost all of the COM-related details from you except for one thing: the threading model. The Internet Explorer COM automation API assumes that you're executing in the single-threaded apartment (STA). This is COM-speak for only allowing one thread to interact with a component. Some test runners use a multithreaded apartment (MTA), which means any thread can access the component. For example, NUnit and MbUnit test runners both use the MTA by default. xUnit, MSTest, TestDriven.NET, and JetBrains ReSharper test runners use the STA. Note that use of a STA or MTA thread for running tests is dependent on the test runner rather than the test framework. TestDriven.NET running NUnit tests will run them on a STA thread, but NUnit GUI running NUnit tests will run them on a MTA thread. To confuse matters even more, MbUnit will override the test runner so TestDriven.NET running MbUnit tests will run them on a MTA thread! This is a long way of saying that you need to run WatiN tests on an STA thread and you better set it yourself to make sure that WatiN can successfully communicate with Internet Explorer. For NUnit, we add an application configuration file called <TestAssemblyName>.dll.config (which in our case is called WebApplication-Test.dll.config) to our test project, as shown below.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
    <sectionGroup name="NUnit">
      <section name="TestRunner" 
               type="System.Configuration.NameValueSectionHandler"/>
    </sectionGroup>
  </configSections>
 
  <NUnit>
    <TestRunner>
      <add key="ApartmentState" value="STA" />
    </TestRunner>
  </NUnit>
</configuration>

On the file properties for WebApplication-Tests.dll.config, change the Copy to Output Directory to "Copy if newer."

If you are using another test framework, you can find information on the WatiN Website on how to properly configure the apartment state.

Just one more change and we'll be able to execute our WatiN tests. Internet Explorer 7 and 8 on Windows Vista or later run in Protected Mode by default. Protected Mode prevents Internet Explorer (and hence any Web content running inside it) from modifying your system. It also hinders communication between Internet Explorer and WatiN. The easiest way to disable Protected Mode for a site is to add it to your Trusted sites list. As shown below, I have added http://www.microsoft.com to the Trusted sites list to run our simple WatiN, as well as http://localhost , since we'll be using a local Webserver to host our test site.

For more detailed information on WatiN and Internet Explorer Protected Mode, see my blog post entitled "Running WatiN Tests on Vista". For more information on Internet Explorer Protected Mode, check out "Understanding and Working in Protected Mode Internet Explorer" in the MSDN Library.

With the test runner's COM apartment state set to STA and Internet Explorer Protected Mode disabled for http://www.microsoft.com, we can execute the simple WatiN test from above which browses to the Microsoft home page and verifies the page title.

Read the full article at http://msdn.microsoft.com/en-us/magazine/dd744751.aspx

New Web Test Debugging Features in Visual Studio Team System 2010

Brian Keller — Tue, 26 May 2009 17:59:00 GMT

In this video Ed Glas shows off new Web test debugging features in Visual Studio Team System 2010, including Search in playback, view recording log, jump to Web test, and Add Extraction Rule from Playback.

Anu Arora: Software Testing (R)Evolution

Charles — Mon, 25 May 2009 19:20:00 GMT

Anu Arora is a Principal SDET(very senior level) with the Engineering Excellence team. As a part of the Software Test Engineering Excellence team, she is chartered with helping everyone in the testing discipline at Microsoft get better through training and consulting. With a passion for quality, Anu is a huge advocate for the testing discipline and has spent her entire nine-year career at Microsoft in testing. During her journey, which started as an SDET to a test lead to a test manager and then back to being an individual contributor (IC), she learnt a few lessons along the way and she shares them in this interview on WM_IN.

This week on C9: Windows 7, WPF futures, and use UI testing to automate your job

Brian Keller — Sat, 09 May 2009 09:25:00 GMT

This week on Channel 9, Brian and Dan discuss the top developer news, including:

- Windows 7 RC is available to download now
- Yochay Kiriaty Windows 7 videos
- Windows 7 Taskbar: Changes from Beta to RC
- Windows 7 Taskbar: Advanced Features
- Windows 7 Multi Touch: Overview
- Windows 7 Multi-Touch: Part 1
- Windows 7 Multi-Touch: Part 2

- Windows SDK and Windows API Code Pack for the .NET Framework available, via Tim Sneath's Developers Guide to Preparing for Windows 7
- Michael Scherotter - New York Times Silverlight SDK
- Bill Buxton - On Engineering and Design - an Open Letter
- Silverlight blog: Expression Gallery to share images, WPF themes, CSS templates, XAML behaviors, and more
- Frank La Vigne - Star Wars Scroller in Silverlight 3, via Alvin Ashcraft
- WPF Futures released on Codeplex, includes Shader Effects, Splash Screen, Client Profile Configuration Designer, WPF Themes, M-V-VM Toolkit, via Lester Lobo
- Ayende Rahien - Are Util & Common libraries evil?
- Brian Peek: How to configure your device emulator to work after adding Windows Virtual PC to Windows 7 RC
- VS Gesture project, via Greg Duncan, and discussion on how you could Multi Touch enable Visual Studio
- Code Project: Improve performance of calculating image sizes using a binary reader
- Silverlight Blog - NBC Olympics wins an Emmy with Silverlight for Outstanding New Approaches Sports Event Coverage.
- Christian "Littleguru" Liensberger becomes a Microsoft employee!
- Brian's pick of the week - 10-4 episode on Functional UI Testing and discussion how you can use it to fake working
- Dan's pick of the week: Coding4Fun: Dan Waters article on Building Multiplayer Texas Hold 'Em Poker for the Zune

10-4 Episode 18: Functional UI Testing

Brian Keller — Wed, 06 May 2009 13:57:00 GMT

In this episode of 10-4 we look at a new type of test coming in Visual Studio Team System 2010 known as the coded UI test. Coded UI tests can be created to automatically navigate through your application's UI, which in turn can be used to verify that the paths your users might take through your application are working properly. You can also add validation logic along the way to verify the properties of objects within the UI. Much like unit tests can quickly surface regressions on a method or function level, coded UI tests can bring the same level of rapid automated testing capabilities to the UI layer.

This demo is based on an early build of Visual Studio Team System 2010 Beta 1.

For some relevant team blogs check out:

Amit Chatterjee's Blog
http://blogs.msdn.com/amit_chatterjee/

Mathew Aniyan's Blog
http://blogs.msdn.com/mathew_aniyan/

10-4! Over and out!

Suneetha Dhulipalla: Making Office for the World

Charles — Thu, 02 Apr 2009 21:34:00 GMT

Suneetha Dhulipalla has been at Microsoft for 10 years, and is currently a test lead in the Global Experience Platform (GXP) group under the Office Shared Services (OSS) division. She and her team are responsible for developing engineering infrastructure and process that will help ship a high quality Office 14. Suneetha’s philosophy is that successful women at Microsoft demonstrate confidence, effective communication skills, passion, persistence, drive for results, and believe in themselves. Watch her interview to hear more!

Ramona Pousti: Visio, Software Testing, Technical Communication and Gender

Charles — Tue, 17 Mar 2009 20:35:00 GMT

Meet Ramona Pousti who works in Office on the Visio team. She took a programming class in high school, and from there her high-tech world took off. After interning at Microsoft, she joined the company when she graduated from Cornell and now she works on a product that reaches millions of folks, and bonus, it’s an application that her mom can understand – still highly technical but you don’t have to be a developer to get it! Ramona also talks about technical communication and how it’s the universal language of geek. :)

Dona Sarkar: Testing Software and Advocating Customers

Charles — Thu, 12 Mar 2009 22:57:00 GMT

Meet Test Lead, and author, Dona Sarkar. She hails from a family of engineers, and she’s one too, but she also writes fiction books for teenage girls. Wow! We could tell you more about her story, or you could just watch Dona tell it as she chronicles her career and the interesting twists and turns it’s taken. As we’ve said before, and Dona continues to prove it, it takes all types. The more diverse you are, the better.

UI Automation Testing with Visual Studio 2010

Charles Sterling — Mon, 16 Feb 2009 21:50:00 GMT

Just playing with some of the new Testing features in Visual Studio 2010 and thought people might be interested in the new interface for Camano and a new feature for CodedUI Tests...pulling the automations strips directly out of TFS!

PS my apologies about the sound...i need a new headset!

Michal Moskal - VCC, The Verifying C Compiler

Peli de Halleux — Fri, 30 Jan 2009 10:25:00 GMT

Michal Moskal gives us a short introduction at the Verifying C Compiler (VCC) project. VCC is a tool that proves correctness of annotated concurrent C programs or finds problems in them. VCC extends C with design by contract features, like pre- and postcondition as well as type invariants. The current primary goal of the VCC project is to to verify Microsoft Hyper-V. Hyper-V is a hypervisor -- a thin layer of software that sits just above the hardware and beneath one or more operating systems. The Hypervisor verification project is a cooperation between European Microsoft Innovation Center in Aachen, Germany the RiSE group at Microsoft Research in Redmond and the Saarland University in Saarbrücken, Germany.

VCC slide deck, get the high-level picture and more details,
VCC home page, all you want to know.
Unfortunately, there is currently no download available of VCC.

The Research in Software Engineering team (RiSE) coordinates Microsoft's research in Software Engineering in Redmond, USA.

IE 8 Behind the Scenes: Testing IE

Charles — Thu, 29 Jan 2009 21:19:00 GMT

Internet Explorer, like all applications released by Microsoft and other software companies, undergoes immense amounts of rigorous testing before being released in the wild. Given the nature of what IE does (compute, calculate, and render random HTML strings into a coherent pixel mesh that adheres, as best as possible, to some set of standards, parse and execute random javascript, host and run COM objects in form of add-ons, etc) the testing matrix is enormous. How complex is the testing process for IE? Well, let's find out, shall we?

Here, we meet three people who absolutely know how much of a challenge it is to test IE and ensure overall quality of any given release: Test Manager Jason Upton, Software Developer in Test Jim Moore, and Test Lead Kris Krueger.

Tune in. It's great to hear from the testing perspective. Testing an internet facing application like Internet Explorer and ensuring a high quality product leaves the building is quite a daunting and, from the outside world's perspective, thankless task. From all of us here, however, THANK YOU IE TEST TEAM!!!!

Inside IE 8 RC1 with Dean Hachamovitch and Jason Upton

Charles — Mon, 26 Jan 2009 22:34:00 GMT

IE team General Manager Dean Hachamovitch and IE Test Manager Jason Upton sit down with me to discuss the significance of today's IE 8 RC1 release. What did the IE team learn from the Beta 2 release? What changes did they make in response to customer feedback? Will the IE team still take and act upon fedback now that RC1 is here? With so many browsers on the market today how does IE remain competitive and maintain marketshare? No conversation on IE can be complete, of course, without talking about the web platform and standards so we go there....

Of course, you can expect this discussion to continue at MIX09 (and you'll be a key participant in the conversation with Dean and team in Vegas).

See the IE Blog for more detailed info on what's in IE8 RC1.

Tune in. This is a great conversation with two key leaders behind and in front of IE (Dean is the all up team leader (as you know by now given how many times you've seen him on C9 and at various conferences) and Jason is responsible for overall product quality (he owns the stuff you seldom see or hear about - software testing)).

Getting started with Pex in Visual Studio 2008

Peli de Halleux — Wed, 14 Jan 2009 19:38:00 GMT

Nikolai Tillmann and Peli de Halleux give a short tutorial on Pex, an automated white box testing tool for .Net. The tutorial is a pair-programming session where they show us how to get started with Pex in Visual Studio, starting from an (untested) piece of C# code:

how to use Pex to explore the behavior of any method in your code,
how to save the exploration results into a unit test suite,
how to improve the generated parameterized unit tests to leverage Pex code exploration engine.

If you want to follow up the steps on your machine as well,

The Research in Software Engineering team (RiSE) coordinates Microsoft's research in Software Engineering in Redmond, USA.

Entries tagged with testing - Channel 9

Wolfgang Grieskamp and Keith Stobie: Spec Explorer - An Overview

SpecExplorer: Model-Based Testing made practicable

Pruebas Unitarias (Unit Testing) con Visual Studio

ARCast.TV - How to Improve Testability with a Modular Architecture

Windows 7 Compatiblity Screencast: Effective Windows 7 Testumgebung aufbauen

Patrice Godefroid - Automated Whitebox Fuzz Testing with SAGE

How Attachmate Earned Windows 7 Software Logo

p&p Acceptance Testing guide Beta 2 is now available

What is acceptance testing?

Sebastian Burckhardt - Data Race Detection with CHESS

Extreme ASP.NET Makeover: Testing - Acceptance Tests

Acceptance Tests

Other videos from this article

Read the full article at http://msdn.microsoft.com/en-us/magazine/dd744751.aspx

Extreme ASP.NET Makeover: Testing - Eliminating Repetition from Tests

Eliminating Repetition from Tests

Other videos from this article

Read the full article at http://msdn.microsoft.com/en-us/magazine/dd744751.aspx

Extreme ASP.NET Makeover: Testing - Using WatiN

Using WatiN to Test a Local Web site

ASP.NET Development Server on Windows Vista and Later

Smoke Tests

Other videos from this article

Read the full article at http://msdn.microsoft.com/en-us/magazine/dd744751.aspx

Extreme ASP.NET Makeover: Testing - Of Tightropes and Tests

Of Tightropes and Tests

Testing Landscape in an ASP.NET World

Automated Acceptance Testing

Introducing WatiN

Setting Up WatiN

Other videos from this article

Read the full article at http://msdn.microsoft.com/en-us/magazine/dd744751.aspx

New Web Test Debugging Features in Visual Studio Team System 2010

Anu Arora: Software Testing (R)Evolution

This week on C9: Windows 7, WPF futures, and use UI testing to automate your job

10-4 Episode 18: Functional UI Testing

Suneetha Dhulipalla: Making Office for the World

Ramona Pousti: Visio, Software Testing, Technical Communication and Gender

Dona Sarkar: Testing Software and Advocating Customers

UI Automation Testing with Visual Studio 2010

Michal Moskal - VCC, The Verifying C Compiler

IE 8 Behind the Scenes: Testing IE

Inside IE 8 RC1 with Dean Hachamovitch and Jason Upton

Getting started with Pex in Visual Studio 2008