Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is there anything wrong with putting test methods in the same class you're testing?

Is there anything wrong with putting test methods in the same class as the class you're testing?

So add the [TestFixture] attribute to every class and have [Test] method alongside the actual methods.

I like the idea. Keeps everything in one place.

But what, if any, are the downsides to this ?

/I use Nunit and c#.

like image 617
arkina Avatar asked Apr 13 '11 15:04

arkina


People also ask

Can we mock method of same class?

We can mock runInGround(String location) method inside the PersonTest class as shown below. Instead of using mock(class) here we need to use Mockito. spy() to mock the same class we are testing. Then we can mock the method we want as follows.

Is it wrong to test private methods?

The short answer is that you shouldn't test private methods directly, but only their effects on the public methods that call them. Unit tests are clients of the object under test, much like the other classes in the code that are dependent on the object.

Should you mock the class under test?

If your class is simple, you shouldn't feel the need to mock out pieces of it during a test. If your class is complex enough that you feel the need to mock, then you should break the class up into simpler pieces.

Is it good practice to make all methods public?

Yes it is very bad practice - you're letting your tools make design decisions for you. I think the main problem here is that you're trying to treat each individual method as a unit. This is generally the cause of all unit test woes.


4 Answers

Yes this is a pattern to be avoided. Tests should be a completely separate entity from your shipping code for at least the following reasons

  • Having tests in a separate assembly help ensure you have a usable API as they can't cheat via private / protected constructs. Instead they are forced to go through the public API points
  • Having tests in the same assembly means your production code also includes your test code. No reason to ship code to the customer they won't actually be using
  • Causes production code to take dependencies on assemblies they don't need (Nunit, xunit, etc ...)
  • Many testing frameworks require test methods to be public hence it pushes tests to the public surface of your API.
  • Having them in the same assembly opens the door to production code accidentally calling into test code and hence fun asserts popping up in production environments
like image 167
JaredPar Avatar answered Oct 18 '22 09:10

JaredPar


This approach grates my soul.

I think it makes a lot more sense to keep your test code separate from your production code. Many reasons:

  • Theoretically, you should be testing at the interface of your code and not have access to things like the private members behind the scenes.
  • Organization - having all of your tests in a separate project means your main application won't be cluttered with test code.
  • This would bloat the size of your deliverables.
  • Putting everything in one place makes it harder for a team to work on the codebase at the same time (one person on tests, one on the code, etc).

Most of all:

It just plains feels / smells wrong.

like image 33
RQDQ Avatar answered Oct 18 '22 09:10

RQDQ


Yes. It would be breaking Single Responsibility Principle. It will reduce the readability. You add a dependency to your testing framework.

like image 43
jgauffin Avatar answered Oct 18 '22 09:10

jgauffin


Biggest downside: you have to ship your tests, and they potentially become part of your public API.

like image 28
Dan Puzey Avatar answered Oct 18 '22 09:10

Dan Puzey