I was a little surprised that I couldn't find a NAnt task to do gets and checkins for MS Team Foundation Server. I found a couple places where someone talked about using NAnt's <exec> task to invoke tf.exe directly. And this
SourceForge project named VSTSPlugins that promises some type of NAnt integration but hasn't released anything yet. Is there something out there and I'm just missing it? As an interim step before porting all of our builds to MSBuild, I'm interested in just switching our NAnt builds over to use TFS instead of VSS. Has anyone experimented with this?
Some things in batch files seem like they should be so simple, but I'm embarrassed to say how long it took to come up with this little trick. Maybe YOU knew it already, but you should have posted it in your blog so I could have googled it and been done in the 10 seconds it SHOULD have taken me to solve it :-)
In case you ever have wanted to take the console output of a command line tool and capture it in an environment variable, this works. There may be better ways. Thanks to Scott Colestock for helping dig this one up.
setlocal
sometool.exe > temp.txt
set /p TOOLOUTPUT= < temp.txt
del temp.txt
..do something with %TOOLOUTPUT%...
endlocal
Of course when Monad comes out none of this monkey business will be necessary. By the way, I just listened to another great Hanselminutes podcast on Monad that has convinced me to give it a whirl http://www.hanselminutes.com/default.aspx?showID=12.
Since I'm on the topic of useful/(or useless?) batch file tricks, another little known one I find myself using alot is the "%~dp0" macro which resolves to the fully expanded path to the directory containing the batch file. This allows batch files to run regardless of the current working directory. So for example Visual Studio post build events run with the current working directory set to bin\Debug or (bin\Release). But you probably have the postbuild.bat file sitting up a couple directories along side the csproj/vbproj project file. So adding a %~dp0 in front of things you do in the batch file give you location independence without having to do hard-coded paths or a lot of ..\..'s all over the place. So the following will always find the "sometool.exe" sitting right next to the batch file no matter where it's run from.
setlocal
"%~dp0sometool.exe" > temp.txt
set /p TOOLOUTPUT= < temp.txt
del temp.txt
..do something with %TOOLOUTPUT%...
endlocal
Scott Hanselman's podcast #10 is on functional web testing tools http://www.hanselminutes.com/default.aspx?showID=11
After listening to it I only had a few comments. Scott hadn't played with the new Visual Studio Team System web tests so he doesn't really talk about it much. I haven't used it much either, but it would fit into his category of HTTP traffic recorders. It doesn't test in the context of the browser like many of the other tools he listed. At first glance I would generally agree with his assessment that it's ACT on steroids. Looks like it will be great for load testing.
I'm personally a big fan of the SWExplorerAutomation tool he touched on. One thing Scott didn't mention that I wanted to point out was a feature that allows you tweak your tests so they continue to work despite structural changes you make to your pages.
By default this tool does record via a positional XPATH. For instance it may record the following XPATH address of an input button.
HTML[1]/BODY[1]/FORM[1]/TABLE[1]/TBODY[1]/TR[4]/TD[2]/INPUT[1]
But if the structure of the page changes, as Scott noted, your XPATH indexes might be off, and you would have to go in and either re-record the scene, or mess around with the XPATH.
BUT by using XPATH, Alex Furman has enabled a more robust way of addressing controls that won't be so fragile. It isn't automatic, but you can easily modify the site structure file to address controls using some other scheme such as ID or text()
HTML[1]/BODY[1]/FORM[1]/TABLE[1]/TBODY[1]//INPUT[@id='MyControlId']
Or if you were going after a Logout link you might address is like this:
HTML[1]/BODY[1]//A[text()='Logout']
I've found this extremely handy for making tests resilient to change.
Some other things I like about SWExplorerAutomation:
- It separates the structure file from the script file so you can record the site structure once, and record many scenarios against it.
- It saves its structure file and script file in plain old XML. It was trivial to write an XSL stylesheet that transforms the script file into an NUnit C# test class.
- It lets you write your tests in .NET rather than having to learn a new programming language.
- Alex is a darn nice fellow and extremely responsive to feature requests
If you haven't checked out the free Visual Studio add-in for unit testing, TestDriven.NET in a while, do yourself a favor. Jamie Cansdale and Grant Drake have been busy.
It now includes a code coverage reporting tool that is quite slick. http://weblogs.asp.net/nunitaddin/archive/2006/03/15/440266.aspx