chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male
0 votes
I use an older version of Typemock, and I am slightly confused. While I write tests, I don't do them everyday to be fluent in them.

My questions are thus:

The older way of doing thigs is using methods which record the expectations, such as:

using (RecordExpectations recorder = new RecordExpectations())
var dataLayer = new DataLayer();
recorder.ExpectAndReturn(dataLayer.GetCustomer(0), customer);

The pattern is, we record our expectations and then run the method (is this a mock object?) to see if we get the right result as expected.

However, now the pattern is:

var v = Get<Type> etc etc. Real example from ... esting.php :

public void GetCustomerPriceGroup_Adult()
var dataLayer = Isolate.Fake.Instance<Datalayer>(Members.ReturnRecursiveFakes);

var carInsurance = new CarInsurance();
PriceGroup priceGroup = carInsurance.GetCustomerPriceGroup(0);
Assert.AreEqual(PriceGroup.Adult, priceGroup, "Incorrect price group");

I assume this is the same thing as recording expectations?

Basically, the syntax is .NET 3.5 I am assuming this is just because the product has moved on? Is there any reason not to use the recorder (wrapped in a using block)?

Also, Isolator checks the validity of arguments. This is exactly what NUnit does. It seems like I could ditch NUnit?

I'm ok with unit testing, but mock testing and writing good business logic to make the tests easier to write is a skill I need practise in. Any tips/urls/books which can help with this will be appreciated. :)

asked by GSS35 (600 points)

1 Answer

0 votes

Let's take it one by one.
The new API, called Arrange-Act-Assert, replaces the old record-replay syntax. There are many reasons for that, but suffice it to say it's much simpler, and we put new features in it. For example, the recursive fakes are not available in the old API. You can read more on the AAA syntax in our blog. If you're just starting out, use the new API.

The use of the 3.5 syntax was chosen because it gave us use type-safe APIs. It reduces the risks of returning wrong objects from a different type.

The feature you refer to in checking arguments allows you to check that at runtime, inside the production code, the correct arguments were transfered to a dependency. You cannot ditch NUnit (or MSTS) because they are the test runner. Isolator still needs them to run.

We have tons of information on our blog. So I'd start from there.

answered by gilz (14.5k points)