Looks like you're missing a lot of the benefits of doing full-blown TDD
(test driven *design*) using Testdriven.NET (TD.NET) and
NUnit/VSTS/other test frameworks.
The rudimentary test harness you described is not good for keeping
regression tests that you can use to ensure you don't break existing
functionality when fixing bugs or adding new features. Most of the
process you described is pretty much instantanous and easily achievable
with TD.NET. For example, I write unit tests methods, hit Ctrl+Shift+T
(I assigned that shortcut to the Run Test command), and get the result
of running the test right in the VS output window within seconds. And I
can run a single test method, all test methods defined in the class
(so-called test fixture) or on the entire project/solution
folder/solution. If I need to debug, I set a breakpoint and hit
Ctrl+****+Y (my shortcut for Testdriven.NET Debugger command).
Tests should NEVER be changed once they pass and test a solid piece of
functionality (unless you need to fix compile errors based on
I can see the advantage of being able to "play" with your assembly
interactively in powershell, but I wouldn't use it at all for real
testing of my classes. Tests are part of your deliverables (if you ship
source) and an invaluable asset in evolving them. Without a broad and
ever-increasing set of tests you can never be sure if you're breaking
In any case, having a standalone analyzer and having a VS integrated one
can be easily achieved nowadays with the new VS SDK. It should be just a
matter of putting your pieces of UI (user controls I assume) inside the
wrapper toolwindow and document window hosts that the SDK provides. So
you could most probably maintain a single code-base.
If you would opensource the project, you might probably find someone
interested in contributing features such as that
Anyway, thanks a lot for an very promising product!
Daniel Cazzulino | Solutions Architect MVP | ClariuS Consulting SA |
425.329.3471 | email@example.com
"He who is good for making excuses, is seldom good for anything else."
From: Karl Prosser
Posted At: Tuesday, August 22, 2006 11:05 AM
Posted To: microsoft.public.windows.powershell
Conversation: Powershell Analyzer Alpha released to the public
Subject: Re: Powershell Analyzer Alpha released to the public
Though that would be nice. THats not on my radar, and i have alot on my
radar. its just not a good enough return (being able to add new
features) for my investment (time). Also though powershell analyzer is
in many ways a great tool for developers, and scripters, a good chunk of
the targetted users are admins, who don't have visual studio. I want it
to not have to require visual studio to be installed, but just require a
small footprint (dotnet 2.0,
powershell) and of course itself.
However I use it as part of my methodology for building C# assemblies
extensively. It allows me to design and unit test classes as i go along,
and build a few lines of script here and a few lines of script there to
unit test, and dynamically interact and prod with the classes i am
building.. this is how i do that
I have my visual studio project that has my assembly DLL in it.
It set the run target to powershell analyzer (i.e
c:\whatever\powershellanalyzer mytestscripts.ps1) i have the parameter
name a script file so its automatically opened..
then inside that script file, i put regions (which in powershell
analyzer you can contract so you just see the text, and highlight the
region and press
f5 and run ALL the codein that region
the first region i put loads my assembly into memory.
then i have regions that test various functionality of my class.. and of
course at any time I can type and run whatever i want.. but i've found
this workflow to be amazingly productive.. in the past you'd have to
write a test harness sort of app, that has a form and a button
keep changing that app.. anytime you'd wnat to interact with the object
you are working with, you'd have to change code and recompile your test
harness, now you just type whatever in powershell analyzer.. the only
time you have to recompile is when you've made changes on the main
assembly you are working on.
Also with this technique you can put breakpoints in your C# code, and
trace through that.. while you are running your test/experimental code
This was a great boost in productivity for me when i was building a
powershell snapin that has a provider and set of cmdlets. As i had a
script with various regions to register, load the snapin, and test
various functionalities.. so i would make changes in my snapin, then run
through a quick list of tests to make sure i didn't break anything, just
by highlighting different regions and pressing f5, and looking at the
then i would dynamically type powershell stuff to interact with the new
functionality i had made..
over and out
"Daniel Cazzulino" wrote:
> This is a fantastic tool Karl!
> One suggestion: is there any chance that you can integrate this into
> VS as a toolwindow and accompanying document window? You could reuse
> the property browser by implementing the selection container
> functionality too.
> Daniel Cazzulino | Solutions Architect MVP | ClariuS Consulting SA |
> 425.329.3471 | firstname.lastname@example.org "He who is good for making
> excuses, is seldom good for anything else."
> -----Original Message-----
> From: Karl Prosser
> Posted At: Thursday, August 17, 2006 4:57 PM Posted To:
> Conversation: Powershell Analyzer Alpha released to the public
> Subject: Powershell Analyzer Alpha released to the public
> from my blog: http://www.karlprosser.com/coder/?p=49
> Hello all, I have decided to release powershell analyzer to the
> general public now. I had wanted to wait until i had completed a few
> more features , however i am not as far along as i wanted to be, as
> i've been in the process of changing jobs and enjoying summer with my
> Anyhow all of you can now get the last alpha (version .11) from here
> it works with powershell RC1 refresh ...
> it is lacking in some of the features , but it much further along than
> the version shown in my old flash demos. (which you can see here and
> As for the future of powershell Analyzer. I finally got my dev VM back
> up and running and compiled it for the first time in a couple of
> months last night. I am currently redoing the threading model yet
> again, to better handle Suspend shells, but the features to expect in
> the next version are
> Return of suspend Shell.. In the old MSH analyzer you could invoke a
> suspend shell, but currently you can't. However that will return, with
> a better GUI experience and way of dealing with it, especially taking
> into consideration when you have multiple runspaces open.
> Return of Immediate Mode.. In the old MSH analyzer i had an "immediate
> where you could just a line of code and press enter and it would just
> run there and then. THat will be making a comeback, and will have
> mostly the same Code Completion features as the main editor Return of
> History. You'll no longer be historyless. Command History is coming
> back to a powershell analyzer window near now.
> GUI makeover. I'll be redoing the GUI a bit, giving it a more VS.NET
> look and feel.
> RICH OUTPUT. Currently the rich output is limited to 1) a property
> an powerful XML visualizer, and a general table. However the rich
> output for hashtables (associative arrays) will yes RETURN. plus
> however there should be some other rich output visualisers added for
> showing dotnet datasets, powershell formated lists, and groups and
> i suppose i could call that release "Power Shell Analyzer - the Return
> There is alot more coming as well, but i want to get out a solid
> release for the whole public soon, so i will limit the features to
> those above (as well as a variety small ones that are quick to
> Then after that i plan a couple of webcasts on powershell in the
> context of powershell analyzer.
> Also soon i will announce an exciting joint venture that should add
> value to the powershell user community.
> - Karl