Major new version in the works - What features do you want?

• Ability to have multiple versions of Typemock installed simultaneously. I realize only one can run at any given time, but having multiple installed with an ability to switch which one is "active" would make life easier.
• Support for advanced async testing. I'm not sure what form this would take, but here are some examples:
  
  • Say I have a WCF service I write and my client calls the service asynchronously (MyService.BeginOperation(), MyService.EndOperation() - not the "event-based async model"). I don't actually want to fire up the service to get that to happen, but there's no way for me to let the Begin call succeed and actually have my async callback called so I can exercise the interaction there. I have to unit test the callback separately. Having some sort of ability to simulate that async call against the service would be huge.
  • Standard thread-safety code like lock/double-check stuff is pretty much impossible to test. Some way to... cause a race condition? mock a lock? I don't know, but some way to test that the double-check code was written correctly would be great.
• Improved exception messages. Some of the exceptions you get from setting up mocks incorrectly are difficult for newer users to resolve because they say what's wrong but don't provide guidance on how to fix it. Something like "You set this up wrong. Check to see if you did this or that in your setup. For more, see the docs on 'mocking instances.'" would be better.
• Fix the stack trace when using decorator attributes. Not even sure if this is possible, but when something goes wrong and you're using a decorator attribute, the stack trace shows this huge section that runs through Typemock and the decorator attribute before you get to the part that actually failed. It makes figuring out what actually happened that much more difficult.
• Smarter build tasks. I've gotten into some odd situations when I have a developer machine with Typemock installed and then run a build script that someone has the "auto-deploy" task running in - my installation gets corrupted and I have to reinstall. If the tasks were smarter so they wouldn't auto-deploy or uninstall on a box the product is officially installed on, it'd save a lot of time. Maybe auto-deploy if it's not installed, but if it's already there, do a build warning that says you're skipping the step.
• More robust tracing. The trace utility is a key benefit to Typemock, and with the VS integration it's even better. Talking to some of the other folks on my team, sounds like "more is better" in this case. Some ideas:
  
  • Add an output window (like debug/trace output, build output, etc. - have "Typemock trace output") that writes a line every time an expectation is fulfilled. People can actually watch things run and get fulfilled as they test in TestDriven.NET.
  • Have the trace utility as a window inside Visual Studio. That way people don't have to leave the IDE or switch applications to see the trace info.
  • More visualizations. For example, right now a mocked method gets outlined in the debugger so you can see it's being mocked. Maybe put something in a watch window or a tooltip that says how many times the current method is going to be mocked and/or where the mock for that particular method got set up so people can trace the setup back to the source. Or maybe in the text editor, have an add-in that highlights any code inside a Recorder block to remind folks visually as they're coding that the stuff in there is mocked. (I might try to write that myself using the DevExpress DXCore add-in engine, too. Could be super helpful and easy with DXCore.)

I'll keep thinking and post more as I come up with them.

• Ability to have Typemock installed but not put in the GAC. Makes it simpler to track down what versions are being used and isolate different projects using different versions if things aren't in the GAC.
• Setting for enforcing behavior like other mocking frameworks. I've heard this mentioned before (I think it was RoyO?) - the idea that you could set some sort of flag so Typemock would "enforce design for testability" like other frameworks. There are some folks around here that would be interested in that.

Great ideas so far - keep them coming!

Travis,

Great bunch of ideas. I'm sure that we will mange to incorporate at least some of them into our next version.
About the WCF - I'm not sure i understand what you need. can you explain it some more? if you can send example by email I'm sure it will help us understand better.
Exception messages - You are right, and we are always making a conscious effort to improve those. I hope that you will see some differences in the upcoming version. However, if you have specific examples that you feel needs to be improved just send them. In most case this can be easily fixed.

With the WCF thing, basically I was just trying to illustrate a situation where I'm making an asynchronous call to some service. It might be a standard ASP.NET web service, it might be a WCF service... or even just a delegate.

Say you have a WCF service that is a calculator - the stereotypical example. It's got a contract that looks like this:

[ServiceContract]
public interface ICalculator{
 [OperationContract]
 int Add(int a, int b);
}

You implement the service.

public class CalculatorService : ICalculator{
 public int Add(int a, int b){
  return a + b;
 }
}

Then you create a client app for the service. Maybe a console app. In Visual Studio, you right-click the project and select "Add Service Reference..." Enter the URL to your service and it pops up, just like classic "Add Web Reference." Select the service and before clicking "OK" set it to "Generate async operations." (You can also do this with the svcutil.exe utility, using the /async option. I think that's what VS is doing under the covers.)

In your client app you now have a proxy with three methods of interest on it:

• public int Add(int a, int b) - To call the service's Add method synchronously.
• public IAsyncResult BeginAdd(int a, int b, AsyncCallback callback, object state) - To start an async call to the Add method.
• public int EndAdd(IAsyncResult result) - To end the async call to the Add method and get the result.

In your client app, you:

1. New up a proxy to your service.
2. Create an AsyncCallback delegate that does something like writing the result of the addition operation out to the console.
3. Call the proxy.BeginAdd method. Pass it your AsyncCallback delegate so that work will get done when the async operation is complete. Store the returned IAsyncResult for later.
4. Do some work. Doesn't matter what. You're doing work while the service is doing some addition for you. The callback delegate will be executed whenever the operation is finished.
5. Wait on the IAsyncResult.AsyncWaitHandle to ensure you don't progress until the operation is done.
6. End the client program.

Again, the idea here is that if I don't actually want to call the service, I can mock the call to "BeginAdd" just fine in step 3, but my callback delegate will never be called in step 4 because there's no real async operation happening, and in step 5 I have to mock the IAsyncResult and just set the waithandle so it won't block the program.

This is the same pattern as calling a delegate asynchronously.

What I'd love to see is something that allows me to mock an async call so that the callback actually does get called and the IAsyncResult is real. Maybe I could specify some sort of duration to wait for the operation to return so I can simulate what it's like to asynchronously call a long-running service operation.

If you still need me to craft up an example, I can, but I wouldn't get stuck on the "WCF" part. I'm more interested in the mocking of an async call to pretty much anything - a service, a delegate, or whatever.