Per Erik Strandberg /cv /kurser /blog


After working with testing for a few years, in a Unix-like environment the last year and becoming a certified tester I felt it was time to take a look at something I had heard a lot about but never had the time really dive into: Testing in Visual Studio.

Visual Studio is quite a beast - it is huge and involves a lot of right-click-configuration - so in my attempt to it I divided the progress into parts.

The parts

In the first part Testing In Visual Studio Part 1 I take a look at (static) code analysis, unit tests and code coverage in Visual Studio. I have had good experience working in similar areas in Python in the past (see for example One Does Not Simply Document Code, Python Doctest And Docstring, Python Unit Test and Python Code Coverage Module), but I only have limited experience of testing in a Microsoft environment (see for example Csharp Unit Test In Sharp Develop for a quick primer on unit testing in Sharp Develop and Visual Studio), and I've only done test-driven development in a small .NET project in the past.

In Testing In Visual Studio Part 2 we will take a look at Coded User Interface Tests - a process of recording actions and assertions in a GUI-way. I also introduce data driven testing. I have tried Sikuli in the past (Sikuli in Wikipedia: [1]) but I have never had good experience of User Interface testing. I know there are some products out there to do this - but I actually found the Visual Studio way of doing it very acceptable, albeit a bit awkward.

In Testing In Visual Studio Part 3 we cover the continuous build process, the awesome continuous integration features in Microsoft Team Foundation Server and also try Gated Check-in's for the first time. For about a year I was on a project that had an mature agile process with nightly builds and some 1500 nightly tests. Moving from nightly tests to a continuous integration approach can be a good approach for some (if not most) projects, but not all.

Possible future parts

In the past I have had a black-and-white view of the world with the axiom that if it's not GPL it's evil. This, of course, made me not really respect Microsoft. I am older now, perhaps a bit more mature - but at least more experienced. So I am comfortable now, when I claim that some Microsoft products are awesome. And I find myself intrigued by some of the concepts they launch (even if they have just stolen the idea from somewhere else and re-branded it - like some say they did when they remade the Java Framework into the .NET Framework).

Anyway: one of the concepts I found intriguing is what Microsoft calls Application Lifecycle Management (or ALM see their page on it: [2]). The thing is that Microsoft want to introduce support for the entire application lifecycle in Visual Studio. Like it or not - I'd like to know more about this and understand it better.

As a part of Application Lifecycle Management I'd like to look at how Visual Studio and/or Team Foundation Server supports working with requirements.

Another aspect of testing in Visual Studio is that we nowadays have a test case work flow - just like bugs can be new, closed, reopened, solved, and so on. I'd like to see this in action an experiment with it.

Belongs in Kategori Test
Belongs in Kategori Programmering