Archives
-
Debugging Tests
If anyone has been having difficulty with the 'Debug Tests' functionality, there's a much more stable version up with build 92. Go to the 'Tools' menu and 'Debug Tests'. This will start a new test process with the debugger attached. You can then set breakpoints, run tests and even compile new tests (which feels strange with the debugger still attached). You won't be able to compile if the process has stopped on a breakpoint (the files will be locked). It's not quite Edit & Continue, but if feels pretty close. Let me know if you have any problems.
-
Stopping on Failed Assertions
After reading the following entry in Dejan's weblog, I decided to see it if what he suggests is possible using NUnitAddin.
-
G: is for GAC
From Jeff Key's .net blog
Using Explorer to get to physical files in the GAC -
Switching Target Frameworks with VS.NET 2003
I can't believe I missed this neat feature of VS.NET 2003. There goes my reason for staying with the old version. 2003 here I come...
-
Spelunking with Ad Hoc Tests
Here's a screenshot showing how easy it is to start spelunking about using Ad Hoc tests. In the example below I've defined a class that creates and disposes of an app domain. All the Ad Hoc test does is return the AppDomain object (which dumps all of its fields and properties). If an Ad Hoc test method is static - the constructor and dispose methods won't be called. Ad Hoc test methods can be private (you won't have to modify your code). At the moment methods with parameters aren't supported. A future version may pop up a dialog box for the parameters.
-
Immediate - Ad Hoc Tests
Okay, as promised I've implemented Ad Hoc tests in the latest build. The idea is to allow any method to be used as an Ad Hoc test. If the class the method belongs to implements a constructor or the IDisposable interface, these will be used to set up and tear down the test (unless the method is static). If the method returns an object, its fields and properties will be displayed (in a similar format the the Immediate window).
-
Installing JUnit & NUnit TestRunners
I've now consolidated the nunit and junit test runners into a single installer. I originaly split them because the junit test runner has a dependence on having the J# runtime installed. I had hoped that splitting them into merge modules would do the trick. Unfortunately it's not as simple as that. From what I can work out there is no way of optinally including a merge module in an installer. Instead you must optionally include individual components (files, registry entries etc.) in the merge module or installer. This is a problem when what you want to optionally install is a merge module. I have resorted to using Orca (the MSI editor) to add dependencies to the J# dependency merge module. Now the installer will only check for the J# runtime if the junit test runner is selected.
-
NUnitAddin + Visual Studio.NET 2003
I've fixed NUnitAddin so that it works with Visual Studio.NET 2003 (and the original version). More later about the issues involved in getting it working. Let me know if you have any problems.
-
Stepping into IL while debugging
.NET Brain Droppings
This post came across the ADVANCED-DOTNET list several months ago and I had to post it. Many of us want to be able to step into the IL as we are debugging, but we can't. This suggestion was provided as a work around by Craig Andera and seconded by Mike Woodring. It's a great way to view the IL as your debugging; lets hope MS will make this easier in the 2nd drop of .NET. You can find the post in the archives here.(1) decompile your assembly using ildasm to get an IL source file that includes the original high level language in interspersed comments.
(2) recompile the IL into an assembly using ilasm.exe
(3) debug the assembly; now able to see source+IL+asm -
NUnitAddin J# Dependency (Fixed)
The previous build picked up a dependency on having the J# redistributable installed. In this build I've split support for J# NUnit and junit projects into a separate installer. Install both packages if you want support for junit and all J# 'New Project...' wizards.
-
Pluggable TestRunners
I've been moving towards a more extensible test runner framework. My first implementation using the new framework is support for junit. I was pleased to find that the 'junit.framework' assembly compiles out of the box with the J# compiler. I have made one minor tweak to it though. .NET behaves slightly different to Java when throwing exceptions. Java fills in the stack trace when an exception is created, whereas .NET does when it's thrown. I've modified junit so it stores the exception without rethrowing it. This preserves the useful stack trace information when a test fails.
-
eXtensible C# is cool!
I've had a go and it really works! I've made a tweak to NUnitAddin so they play nicely together (save all files before build). eXtensible C# handles its assertions using the TraceListener framework. These messages will show up when running a subset of tests using the code context menu. Adding failing non-terminal assertions to the Task List is on my todo list.
-
Save, Build, Test
The very anoying bug where source files weren't being saved before building and testing has been fixed! This was only ever an issue for J# and C++ projects from what I can work out.
-
IntelliSense in Immediate Window
VS.NET 2003 Delivers Solid Enhancements, Microsoft Promises Even More in 'Whidbey'
-
Pressing CTRL-C on a Windows Dialog Box
I've just received a bug report with the following note...
-
Trace and Debug Output
Too many times I've found myself adding and removing Console output to my tests. I've added it when I need more information about how an individual test is running. I've removed it when cleaning up the output from running all tests in an assembly. I've found what I think is an effective solution.
-
Attaching to a Process using VS.NET Automation Model
I've recently changed NUnitAddin so that it runs unit tests in an external process. It controls and communicates with this process using .NET remoting. Because tests are run in an external process it's possible to attach the VS.NET debugger set breakpoints on them. When I manually attach the CLR debugger (as follows) it works great.
-
Screenshots
I've started working on a guide to using the addin. All there is so far is a number of screenshots. You can tell pretty much how it all works just from them.
-
Enumerating AppDomains
Have you ever wondered how to enumerate all AppDomains in the current process? It can be done with a little COM interop...
-
Making Test a First Class Citizen
The aim of the project is to make Test a first class citizen inside Visual Studio.NET. Test should be as integrated and natural a part of your development environment as Build is today. Wherever you find a Build action you could also expect to find a Test action. For example there is an action to Run Tests in a Project or Solution. There is also an action to Run Test(s) on the code context menu. Which tests are run depend on whether you click inside a Test, TestFixture or Namespace. Obviously this doesn't correspond to Build (until we get Edit & Continue that is ;). The corresponding Build action will be performed before any tests are run (Test depends on Build).
-
NUnitAddin Weblog
Welcome to the NUnitAddin project weblog. My inspiration for starting this is Jeroen Frijters IKVM.NET Weblog. I have enjoyed watching his project progress over the months. Where as this is no way near as ambitious, I hope people will find it useful.
