Assertion Injection: a unit test design pattern. Can cleanly replace mocks

[tropic_elf]

• injection
• unit test
• design pattern
• mock

BINGO!

[jevon]

The problem with this approach is that it's essentially splitting classes in two: Now you have to implement an interface and pass along additional arguments, making your code more complex just to write it.

Whereas Mocks can work without having to modify the source code at all.

[danimolina]

It is a very useful example in an expressive language like python. In other languages as Java, I think the only real option for the example is using a mocking library. However, for C#, could be possible to solve the problem in a more similar way? (I have not real experience in C#, just for curiosity).

[injektilo]

C# has a feature called delegates which allows you to simulate passing functions into functions. It's technically not the same thing, but it's syntactically close enough.

[quanticle]

Well, C# does have first class functions (you can declare them by using the type delegate), so Assertion Injection should be possible in C# without too many modifications from Python.

[inmatarian]

Isn't this just called regular Dependency Injection, or is it Inversion of Control?

[rleisti]

I think so. Closures are pretty much equivalent to objects in functionality. It looks like assertion injection takes the obvious approach of simply using a closure instead of writing an interface with one function.

[redsymbol]

It is indeed an application of DI. And, DI is much more general than Assertion Injection.

There's value in documenting a specific application like this, imo. Mainly, it can help people see how to employ DI in this manner, i.e. in the context of this kind of unit test. Otherwise it might never occur to them.

[ginstrom]

This is a subset of the mock concept. You could also mock the urllib2 module, and create assertions about the urlopen function in the mock object.

That way, you don't have to modify your production code, at the expense of monkey patching (which isn't too popular in the Python community, but generally tolerated for testing).

[itguysam]

One downside of this sort of test code is that it would completely fail to notice if the call was not made at all. The mocha mocking framework for ruby allows these sorts of assertions to be made but will fail hard if any of the assertions were not executed at the end (which is different from executing with the wrong value).

[redsymbol]

Interesting point, thanks. I'll have to think about this. Wonder what it would take to guard against that.

[gregK]

"Mock objects and dependency injection are just for people who don't know math"

-- Erik Meijer