Choosing a unit test framework

22 views
Skip to first unread message

Abraham Shilon

unread,
Jun 23, 2016, 6:26:14 AM6/23/16
to altnet...@googlegroups.com
Hi guys,

I know that this subject has been asked and discussed a billion times already. So sorry about that.
But as someone who hasn't been updated in the unit testing landscape for some time now, I'm feeling that things have changed since the last time I called Assert() on NUnit :)
The thing is that I've started working at a place that is, well, not industry leading to say the least, in terms of technologies used, but we want to changed that, so this might a first in several "helping" mails on my side. So yes, i saw on the internet frameworks like moq, nsubsitute, fakeiteasy etc. but the best solution would be to ask someone who is already using them (hint=> hint.youGuys), and perhaps tried several of them too. 
So, it's not a religious thing, this email, just asking for some help getting us off the ground here guys. 

I really appreciate any help guys,

Thank you,

Avraham Shilon

Boris Modylevsky

unread,
Jun 23, 2016, 7:47:54 AM6/23/16
to altnet...@googlegroups.com
We're using the following set of frameworks:
- NUnit
- FakeItEasy 
- FluentAssertions

I found them the most readable, easy to teach and easy to write.

IMHO,
Boris



Boris Modylevsky

Agile Developer & Coach

 

Mobile:  +972-526-377-300

Email:   bori...@gmail.com

Blog:     www.borismod.net

Twitter: https://twitter.com/bormod

Github:  https://github.com/borismod


--
You received this message because you are subscribed to the Google Groups "altnetisrael" group.
To unsubscribe from this group and stop receiving emails from it, send an email to altnetisrael...@googlegroups.com.
To post to this group, send email to altnet...@googlegroups.com.
Visit this group at https://groups.google.com/group/altnetisrael.
For more options, visit https://groups.google.com/d/optout.

Igal Tabachnik

unread,
Jun 23, 2016, 7:49:37 AM6/23/16
to altnet...@googlegroups.com
Agree with Boris, some times the most familiar things are the best.
NUnit + FluentAssertions + FakeItEasy (if you must) is the best and most supported combo

Abraham Shilon

unread,
Jun 23, 2016, 7:56:41 AM6/23/16
to altnet...@googlegroups.com
@Boris, you're using 3 frameworks at once? Can I please ask why?

@Igal, can you please elaborate on the "if you must" thing about FakeItEasy?

Thanks a lot guys

Boris Modylevsky

unread,
Jun 23, 2016, 8:08:02 AM6/23/16
to altnet...@googlegroups.com
There are used for three different purposes:
- NUnit is the unit testing framework, it's the most popular and it's cross platform 
- FakeItEasy - is the mocking framework. It's used to create mocks in unit test, which is not provided in NUnit OOB
- FluentAssertions - is a more readable way to write assertions, with fluent auto-completion.

So there are three different libraries that are used for different purposes and work great together.

@Abraham, you're welcome to ask me privately, if you have additional questions.



Boris Modylevsky

Agile Developer & Coach

 

Mobile:  +972-526-377-300

Email:   bori...@gmail.com

Blog:     www.borismod.net

Twitter: https://twitter.com/bormod

Github:  https://github.com/borismod


Igal Tabachnik

unread,
Jun 23, 2016, 8:28:35 AM6/23/16
to altnet...@googlegroups.com
Believe me when I say this, I love mocking frameworks for what they do (and I used to work for a commercial one), but I wouldn't use one today.
I've seen so much mocking abuse that I'll die happy if I won't have to mock anything else ever again.
Nowadays I tend to prefer ATDD/EndToEnd style tests, which use in-memory implementations of various dependencies. It's the only way to make sure the system as a whole actually works...

Igal Tabachnik

unread,
Jun 23, 2016, 8:30:09 AM6/23/16
to altnet...@googlegroups.com
btw, ATDD/E2E and similar acronyms are often misused as well. I refer specifically to GOOS (Growing Object-Oriented Software, Guided by Tests) style tests, which is my preferred way of testing today.

Boris Modylevsky

unread,
Jun 23, 2016, 9:00:25 AM6/23/16
to altnet...@googlegroups.com
I agree with Igal, testing against in-memory implementation of the real library is the best way. There are many libraries on the shelf that provide such implementation over file system, database and others:
- System.IO.Abstractions and System.IO.Abstractions.TestingHelpers
- SQLite



Boris Modylevsky

Agile Developer & Coach

 

Mobile:  +972-526-377-300

Email:   bori...@gmail.com

Blog:     www.borismod.net

Twitter: https://twitter.com/bormod

Github:  https://github.com/borismod


Abraham Shilon

unread,
Jun 23, 2016, 10:10:20 AM6/23/16
to altnet...@googlegroups.com
OK, wow!
I had no clue about that GOOS/ATDD/E2E stuff. 

BTW, i've noticed that there is a book that goes by that name, Igal. Did you mean this book, or is it a general concept?

Igal Tabachnik

unread,
Jun 23, 2016, 10:13:10 AM6/23/16
to altnet...@googlegroups.com
Yeah, I meant the book (by Steve Freeman and Nat Pryce). It's Java (heh, most of them are), but the concepts apply in .NET languages as well.
The first half is a bit preachy, but it picks up pace towards the middle.


Ken Egozi

unread,
Jun 23, 2016, 4:58:56 PM6/23/16
to altnet...@googlegroups.com
Per the OP's question - whatever works and familiar. all the unit test frameworks are essentially the same (sans MsTest which is a pain to automate, and also not free IIRC).

Per mock or not - it really depends. Some code paths with complex logic can definitely get a lot of value from well isolated unit tests. Even then I prefer state based functional tests (given some inputs, assert on outputs) than interaction tests (validate(x) was called). But those are *never* a replacement for e2e tests that cover the happy paths and common user stories.



Dotan N.

unread,
Jun 23, 2016, 5:04:00 PM6/23/16
to altnet...@googlegroups.com
mocks are good when you can't have in-memory / operational mocks / an implementation that you can control easily. mock when you don't have control over that "other" codebase.

oh hey, it's alt.net in 2016 :)


--
Dotan, @jondot

Gustavo Ringel

unread,
Jun 24, 2016, 1:37:01 AM6/24/16
to altnetisrael
I found always Mocks useful if I need to call a Robot with a specific set of sequences, or a third party service that should be called with an agreed set of functions and you want to explicit the algorithm because it should not change.
For every other thing, using the real thing works best.

Itzik Saban

unread,
Jun 24, 2016, 3:12:41 AM6/24/16
to altnetisrael

Other than external services such as DB, FSO, etc., I also use mocks whenever my CUT (Class Under Test) depends on a different class that represents only the tip of the iceberg, meaning, this different class holds a huge graph of dependencies underneath it and if you'll try to use a real instance of it, you'll find yourself feeding the beast just to provide all the state it needs to make it pass.
Itzik Saban

Uri Goldstein

unread,
Jun 28, 2016, 3:11:53 PM6/28/16
to altnetisrael
Igal,

Can you elaborate a bit about the sort of abuse you've seen done with mocking frameworks?

I'm aware of the black magic of TypeMock and JustMock so do you have examples of "plain" mocking frameworks being put to bad use?

Tx,
Uri

Uri Goldstein

unread,
Jun 28, 2016, 3:16:12 PM6/28/16
to altnetisrael
Oh, and my two cents about mocking vs in-memory etc -

I love mocking a lot. I prefer my units under test to be small and isolated, that way my tests are short and simple.
I dislike unit tests that target large "units" (multiple classes and dependencies) and complicated scenarios. I leave that to my E2E or large integ tests.

Keeping an open my mind, I'll try and grok that GOOS book. Never heard of it till now so thanks Igal!

Cheers,
Uri

Ken Egozi

unread,
Jun 28, 2016, 3:50:17 PM6/28/16
to altnet...@googlegroups.com
Test code is code. And like any other piece of code, it can be measured in terms of ROI.

Mucking around with dependencies can inhibit encapsulation. The dependencies are are internal implementation details of the unit under test. In a perfect situation the function under test will have no side effects, so given some inputs it would provide some outputs. If it does indeed depend on external data, then providing stubs (or alternatively reproducible in-memory or otherwise test data) is okay as that data would be considered part of the input variations.

If on the other hand you start writing things like "I expect some encapsulated dependency to be called in a certain way", then you are very likely to gain very little validation from the test, and will very likely be required to change the test everytime to refactor the internal implementation of the system under test. At that point, the ROI of the test diminishes and often become negative.

Igal Tabachnik

unread,
Jun 28, 2016, 3:51:45 PM6/28/16
to altnet...@googlegroups.com
Sorry, can't answer properly at the moment, but what Ken said :)
Reply all
Reply to author
Forward
0 new messages