James.Testing.Wcf

James.Testing.Rest is a dead simple library for calling soap-based services. It is designed to be simple enough for QA folks to leverage it in their own automation but powerful enough to be leveraged in multi-threaded scenarios such as performance testing. In order to add it to your projects, you can use the following in the NuGet package manager console.

 >install-package James.Testing.Wcf

Below is a description of the supported features. There will be more coming in the near future!

Service Calls

All service calls begin with the Service keyword and the type of service interface that is either provided by adding a WCF service reference or by referencing a shared contracts library. It uses a fluent syntax going forward. No need for a novice coder to have to new() up any variables. All responses have a Result that is the type specified in the Call method and a Fault that is also related to the type specified in the Call.

Example: Functions - Calling operation with successful result

Service<IPersonService>
	.Call(x => x.GetPerson(new GetPersonRequest {Id = _id}))
	.Verify(r => r.Result.Person.Id == _id)
	.Verify(r => r.Result.Person.FirstName == "Todd")
	.Verify(r => r.Result.Person.LastName == "Meinershagen")
	.Verify(r => r.Fault == null);

In the example above, a result type is not needed because it can be inferred from the lambda funtion that is being used within the Call() method. In addition, if a FaultException is not specified, it will default to the generic FaultException().

Example: Functions - Calling operation with custom fault result

Service<IPersonService>
	.Call<GetPersonResult, FaultException<GeneralFault>>
		(x => x.GetPerson(new GetPersonRequest {Id = _id}));
	.Verify(r => r.Result == null)
	.Verify(r => r.Fault.Detail.Message == "This is the message.")
	.Verify(r => r.Fault.Detail.StatusDescription == "PersonNotFound")
	.Verify(r => r.Fault.Detail.StatusCode == 404);

In the example above, a result and custom FaultException type is specified. This informs the library when returning the fault for further verification.

Example: Actions - Calling operation successfully with no result

Service<IPersonService>
	.Call(x => x.MarkPersonAsFavorite(_id));
	.Verify(r => r.Result == Result.Empty)
	.Verify(r => r.Fault == null);

In the above example, as in the first, no return type is specified because the lambda within the Call() method is an action with a void return. You will notice that the Result property is of type Result and is equal to the Result.Empty value. A FaultException is also not specified, so it is defaulted to FaultException.

Example: Actions - Calling operation unsuccessfully with no result

Service<IPersonService>
	.Call<FaultException<GeneralFault>>(x => x.MarkPersonAsFavorite(_id));
	.Verify(r => r.Result == Result.Empty)
	.Verify(r => r.Fault.Detail.Message == "This is the message.")
	.Verify(r => r.Fault.Detail.StatusDescription == "BadRequest")
	.Verify(r => r.Fault.Detail.StatusCode == 400);

In the example above, the return type is not specified because the lambda is an action. However, the caller has specified a custom FaultException so that the Fault property will be properly typed for further verification. Note again that the Result is of type Result and is equal to the Result.Empty value.

Example: Multi-threaded calling

Action action1 = () =>
	Service<IPersonService>
	.Call(x => x.GetPerson(new GetPersonRequest{Id = Guid.NewGuid()}))
	.Verify(r => r.Result.Person.FirstName == "Todd");

Action action2 = () =>
	Service<IPersonService>
	.Call(x => x.MarkPersonAsFavorite(Guid.NewGuid()))
	.Verify(r => r.Result == Result.Empty)
	.Verify(r => r.Fault == null);

Parallel.Invoke(action1, action2);

In the example above, two actions are prepared calling different operations of the SOAP-based service. Both actions are executed simultaneously within different threads and can maintain different responses. This is particularly useful in performance or load testing cases.