Tag: .NET

Productivity Testing
Handling Arguments in JustMock Arrangements

Mocking is all about making it easy to isolate the system under test in unit tests. In non profiled mocking, this is typically done by creating a proxy for an interface, and arranging the methods that will be called on the proxy. Mocking frameworks like JustMock determine matching calls not only based on the method signature, but also by the values of the arguments passed into the method. JustMock provides many mechanism to tune how the matching is done.

by Phil Japikse
May 27, 2021 5 min read Share
Productivity
Lifesaving Tips for Developers

Read Chris Eargle’s list of lifesaving tricks and tips for developers which may help you avoid losing your job or your project.

by Chris Eargle
January 23, 2024 3 min read Share
Productivity Testing
KickStart Your .NET Mocking

Getting started with mocking can be hard. In this article, I describe the path that I took on my way to becoming a frequent mocker.

by Phil Japikse
May 27, 2021 8 min read Share
Release
Telerik Reporting to drop .NET2.x, .NET3.0, VS2005 and VS2008 support in Q2 2013

Yes, it is about time, and you, our users, have confirmed it in the several polls we ran on the topic. As of Q2 2013 (expected in June 2013), Telerik Reporting will stop supporting .NET2.x, .NET3.0x as well as VS2005 and VS2008. This way the small percentage of our users still using .NET2 and .NET3.0 have several months to migrate their projects to newer .NET versions (.NET 3.5 SP1, .NET4.x). Alternatively, these projects can continue to run against .NET2 or .NET3.0, but they will not be able to use newer versions of Telerik Reporting. Why the change?

by Vassil Petev
May 27, 2021 2 min read Share
Productivity Testing
Asserting Behavior with JustMock

JustMock is a great tool for abstracting dependencies in unit tests, and the new automocking feature makes it even faster to develop unit tests. Another great feature in JustMock and JustMock Lite is the capability to assert the behavior of your system under test. Traditional TDD (Test Driven Testing) unit testing typically tests for state. Did the user get logged in? Did the user’s shopping cart get loaded? Important tests, of course. But that only tests the end result of the method. If the user does NOT successfully login, and the cart is not reloaded, is that because the call to the repository was never called? Or because some error happened that didn’t reload the cart in this particular use case? The state of the application is correct, but is that because it executed the expected behavior, or because we got lucky?

by Phil Japikse
May 27, 2021 5 min read Share