The latest release of my favorite web service testing tool has a really interesting feature:
Support for Mocking of Web Services directly from within soapUI. Mock Services can be run either from inside soapUI or with one of the IDE/Maven/CommandLine plugins.
In a service oriented architecture is usual, and desirable, to have contract definition (i.e. the web service
WSDL and schema) before the service implementation is available or, at least, is robust enough for testing. Having such a tool makes the development of clients for such services much faster and removes the part of the pressure of service implementators.
Mocking web services along with other nice features like unit testing or load testing makes SoapUI probably the best tool for web service testing around, it was the only Java tool I was able to push in the Microsoft-based environment I’m working at.
Web Service Mocking [via SoapUI Documentation]
Technorati Tags: soapui
About a year ago I was looking for a .Net mock object library to use in a project I was about to start, a project where we were planning to use unit testing intensively. Back then I found a couple of small but interesting projects, although none supported .Net 2.0: DotNetMock (the one we end up using) and NMock. Both of them use the same simple approach called dynamic mocks: a dynamic proxy is created from an existing interface (which is good, as it enforces “interface driven” programming), a proxy that allows the definition of expectations for that mock, which are supposed to simulate the behavior of the real object.
But recently we’ve been facing the limitations of DotNetMock, the project has been inactive for a while, which means still no support for .Net 2.0 that lead to “small” issues like no unit testing with things like Generics. That’s why I’ve been seriously considering moving to another mock object library, although it’s something that’s been postponed again and again in the last few months.
Fortunately Paulo has shown me Rhino Mocks (more than once, I admit) and what seemed, in a first glance, a open source implementation of TypeMock had a neat trick of it’s own: the ability to define expectations using objects, unlike all the others I’ve seen where you must a use a string with the method’s name (which very error prone when refactoring). Must take some time to check this one more deeply.
Oh! I almost forgot, and it supports Generics, Nullable Types and all those .Net 2.0 little things…
Technorati Tags: unit testing, nmock, dotnetmock, typemock, rhinomocks
About myself