Archive for March, 2009
A question from Tobbe Ryber has inspired me to jot down a few things I’ve been meaning to do in a more extensive blog post for a long time. But since it hasn’t happened yet, I figure it probably never will, so you’ll have to settle for my abbreviated, half-ass version.
Twenty reasons to use Visual Studio Team System 2008 Test Edition for your software testing automation framework, ESPECIALLY if your development team is using .NET and Visual Studio:
- You are using the .NET platform which is a set of stable and robust libraries that allow you to do just about anything. Make HTTP requests, make Web Service requests, use COM, make database queries, the list goes on and on. Basically anything your .NET developer is doing you’re going to be able to tap into using the same context. Easily.
- You have the ability to easily make calls into several layers of the application under test using a few lines or code, without duct taping and bailing wiring a bunch of libraries or technologies together. Imagine automating something in the browser, making a call to a Web service and then calling the database to validate your results…All in a few lines of code.
- There are awesome tools and libraries that are built on .NET that allow you to automate browsers, such as SWEA, WatiN, and HTTPWatch.
- There is a great library and Visual Studio add-on that allows you to automate multiple browsers (IE 7, 8, FireFox. Safari and Chrome any day now), as well as Silverlight. Best yet, the recorder integrates with the IDE: ArtofTest’s WebAii and Design Canvas.
- Your ‘test harness’ is built into the IDE, and your tests can also be ran from the command line.
- The IDE is top notch when it comes to development and debugging (and test development and debugging). I’ve been using VS for automation since VS 2005, and when I’ve had to automate in other worlds (e.g. Linux, PHP, and Perl) I honestly feel like I’m working with tools that equate to a chisel and stone tablet.
- Auto-complete in the IDE is a huge timesaver. Your time spent searching the internet or referring to a library’s specifications is far less with auto-complete.
- The Microsoft.VisualStudio.TestTools.UnitTesting namespace is not just for unit testing, it works great for test automation. It feels a lot like nUnit to me.
- Integrating your tests with development builds is cakewalk. Using the mstest command line, it’s easy to have your tests run with a build in TFS or CruiseControl.
- You have the ability to easily move some of your tests up the chain to run along side of developers’ unit tests. By doing this you now have automated acceptance tests, so that releases to QA have higher quality.
- You are using the same environment/language as your developers. By doing this, you gain:
- A. The ability to have developers help you with getting over the .NET language or VS IDE learning curve.
- B. Knowledge and use of the same language and libraries used for development, thus having a greater technical understanding of what you’re testing.
- C. Easily share and discuss your tests with developers because they are familiar with the language you are using.
- Test results are in an XML format which means that if you want to use something other than VSTS to view results you can easily manage it.
- The .NET community is huge. Help, technical examples, and issue-workarounds are an Internet search away.
- Examples are SUPER helpful through MSDN. Training video series such as How Do I and VSTS Learn are a great alternative.
- VSTS also does load testing.
- .NET, C#, VB.NET, and Visual Studio experience on your resume are technology skills and buzzwords that lure recruiters.