Blog Archives

Making sure all IWorker implementers call CanHandle from Handle without a mocking framework

lego-568039_1280

You have an interface that allows you to treat all worker classes – classes that handle a specific type of work – as just one type: IWorker;

You want your worker classes to be able to do their work without having to check their backs every step of the way.

Read more ›




How to verify a method actually gets called – without a mocking framework

hard-labor

Hard labor

You have busted your bum writing a solid MagnificentValidation validation method that checks the input data for a whole slew of data manipulation methods. And you, of course, covered it with unit tests so nobody, not even you, can accidentally mess up the validation logic without it being noticed.

Read more ›




How can you check a validation method is called if it just returns an error code

The strategy laid out in Testing strategy for validation and action methods calls for a single test per action method, to show that it actually calls the validation method.

With an exception throwing validation method that test is simple. But with error code returning validation –

Read more ›




Verify a validation method is called that doesn’t throw exceptions

The strategy laid out in Testing strategy for validation and action methods calls for a single test per action method, to show that it actually calls the validation method.

Validation methods throwing exceptions on invalid input provide you with a handy means of checking whether it has been called by your action methods.

Read more ›




Testing strategy for validation and action methods

How do you test a set of methods that call each other without repeating yourself unnecessarily?

You are more than tired of debugging “List index out of bounds”, “Duplicates not allowed” and similar exceptions. You want some help from your code so you don’t have to hit “Next” until you are blue in the face to figure out the information not contained in the standard exception messages.

Read more ›




Testing every implementer of an interface with the same tests using MSTest

You have an interface and multiple implementers of that interface. You want to test all those implementing classes using the same tests. And you do not want to repeat yourself. That would be … like … Gah!

Using NUnit that is a breeze. But you, you use MSTest,

Read more ›




Testing every implementer of an interface with the same tests using NUnit

You have an interface and multiple implementers of that interface. You want to test all those implementing classes using the same tests. And you do not want to repeat yourself. That would be … like … Gah!

Using a unit test framework like NUnit that is a breeze.

Read more ›




How to test a class hierarchy without repeating yourself

You don’t want to spend your effort on futile tasks. And testing all methods of a base class and then testing them again for every descendant sounds futile.

After all, non virtual methods are not going to change in a descendant, so, really, testing the base should be enough?

Read more ›




Property.Settings.Default makes it hard to unit test any method that uses it

Storing your application and user settings should be a solved problem. After all, we have done it since the dawn of software development. Yet, the question “What is the best way to store settings?” keeps cropping up. The answers vary widely and quite often spark religious wars.

As interested as I am in why people are so invested in whatever they use,

Read more ›




Why CollectionAssert.AreEqual fails even when both lists contain the same items

Last time you did this, it worked flawlessly. The test you made verified that an item was added and then returned correctly:

  • Retrieve all items into a “before” list.
  • Add an item.
  • Retrieve all items into an “after” list.
  • Manually add the item to the “before”

Read more ›




Show Buttons
Hide Buttons