TestStand versus Visual Studio .NET

Por algun tiempo hemos estado evaluando TestStand y comparandolo con Visual Studio .NET, tanto asi que ha desatado apasionadas discusiones entre los defensores de uno y del otro. Seria largo, complicado y redundante listar las caracteristicas de uno y del otro aqui, pero un developer amigo mio lo resumio de la siguiente manera...

"TestStand certainly offers a great deal of flexibility in its test executive. My primary question whether to adopt TestStand would be the cost/benefit as it applies to this department. For the type of tests our department produces, my opinion is that TestStand offers less value. Our tests are simple, high-volume and designed NOT to be configurable by the operators.

Adopting TestStand across our test projects would entail ramp up time and I don't think that this effort would payoff much more than we could already accomplish in the .NET environment. I have a project that is close to deployment for most of our test systems. The primary goal of this is maintenance reduction. To that end, the project architecture is modular and easily configurable. Because I was able to build this without being encumbered by our legacy projects, I was free to apply good software design. This project will essentially function as TestStand Lite.

A couple of project features relevant to this subject:

1. Configurable test lists for each UUT (unit under test) type, loaded at runtime. Allows easy modification of tests or test sequence without code changes to the host executable. Similar function as plug-ins.
2. The tests and instrument classes are compiled to .dlls and are no longer coupled to the operator GUI. Code changes to these libraries need not concern themselves with the code controlling the main form or even individual station controls.

An attractive feature of TestStand that deserves review:

AutoSchedule feature: (I'm going to skip an explanation of AutoScheduling vs. basic parallel station model. National Instruments has a .pdf that shows a very nice illustration to compare this to other station models) While certainly not impossible in a pure .NET project, implementing this feature in .NET would be a time sink. However, AutoScheduling is most advantageous when you have the combination of large number of stations (or large number of resources requiring locks) and resources which are locked for long durations. In a multi-station model, we already see large gains in the basic parallel station implementation. My guess, without running any numbers, is that we would see a measurable but not significant gain using the TestStand AutoSchedule feature.

For our department, I see TestStand useful for bench-top development. Such projects would benefit from the flexibility that TestStand brings."

Espero esto les sirva de partida para su propia evaluacion.

Gracias por leer.