.NET news » Testing

You can think of Windows PowerShell as a dramatic upgrade to the old cmd.exe command shell and associated .bat files. Although designed with systems administration tasks in mind, Windows PowerShell has features that also make it ideally suited for lightweight testing tasks. This month, I test Microsoft .NET Framework-based code modules from both the Windows PowerShell command line and lightweight Windows PowerShell scripts.

With over 35,000 downloads of Nunit Framework per month, there is a noticeable trend that Test Driven Development and the values of having a set of Automated Tests are worth the price. Even Microsoft has joined the game and is distributing its own testing framework (we will actually use this framework in the examples of this article). There are many articles about Test Driven Development, but once you start writing tests, you will notice that you start to design your code to become testable. In this article, we will see that these techniques used to create testable code, unnecessarily make your code complex and thus hard to maintain. This is something which is opposite to the Test Driven Way of Creating the Simplest thing that will work.

Failing to adopt an appropriate testing approach to help identify bugs along the development process can have as devastating an impact on your project as a hurried or non-existent design. Fortunately, automated testing tools like AutomatedQA's TestComplete 5 make the process of creating structured testing affordable and significantly less time-consuming.

A lot has been written on the subject of test driven development, and especially on the idea that tests ought to be written first. This is an ideal that I strive for, however, I have a tendency to write the unit tests afterwards.

Some people learn better by example. This article, rather than going in to great length about the principles of test driven development, will walk the reader through the process of building and testing an algorithm by writing the tests first, then changing the method being tested so that it fulfills the tests.

The final code and all the unit tests can be found in the accompanying download. This will require NUnit and Visual Studio 2005.

The dependency injection pattern, also knows as Inversion of Control, is one of the most popular design paradigms today. It facilitates the design and implementation of loosely coupled, reusable, and testable objects in your software designs by removing dependencies that often inhibit reuse. Dependency injection can help you design your applications so that the architecture links the components rather than the components linking themselves.

This article presents an overview of the dependency injection pattern, the advantages of using dependency injection in your designs, the different types of dependency injection, and the pros and cons of each of these types, with code examples where appropriate.

The popularity of Web applications that use AJAX (Asynchronous JavaScript And XML) technology has increased steadily over the past year. When written correctly, AJAX can yield significant improvements in performance and user experience compared with non-AJAX Web applications. However, because AJAX Web applications work asynchronously, traditional synchronous test automation techniques generally don't work. In this month's column, I present a technique that allows you to write lightweight test automation to verify the functionality of AJAX Web applications.

The goal for this column is to show you how to get started with GUI automation using the UI Automation tools and APIs. As with most Bugslayer columns, there's a large set of code that I provide to make your GUI testing far easier than using the API directly.

This article exposes how to use WatiN and how to create UI tests for Web Applications

The popularity of Web applications that use AJAX (Asynchronous JavaScript And XML) technology has increased steadily over the past year. When written correctly, AJAX can yield significant improvements in performance and user experience compared with non-AJAX Web applications. However, because AJAX Web applications work asynchronously, traditional synchronous test automation techniques generally don't work. In this month's column, I present a technique that allows you to write lightweight test automation to verify the functionality of AJAX Web applications.

Many diagnostic tools use the CLR Profiling API-even those that aren't strictly profilers. So if you've ever wondered how these tools work, a look at the Profiling API is a good start. In this column, you'll see how they work and look at some useful tips and tricks. You'll also find some essential resources in the "Other Profiling Resources" sidebar. To use the CLR Profiling API, you create a DLL using an unmanaged language-typically C++, then you set some environment variables that instruct the common language runtime (CLR) to load the DLL and allow it to use the Profiling API. When loaded, this DLL effectively becomes an extension of the CLR itself, receiving callbacks, requesting information, and making changes deep within the implementation of the CLR. The Profiling API can provide notification of many activities within the CLR and managed code, including the creation and destruction of appdomains, loading and unloading assemblies, JIT compiling functions, executing functions, throwing and catching exceptions, and doing garbage collections. Using the Profiling API, you can get information about parts of the application, such as names and locations of assemblies, descriptions of types and functions, and locations and layout of objects in memory. Finally, you can use the Profiling API to modify settings, instructions, and the like, including disabling optimizations in the JIT compiler, changing the intermediate language (IL) for a function, or even creating new types and functions..