Is there a way to exclude private methods from the tests, such that the black bar is not generated for private methods, and their code coverage doesn't affect the code coverage of the class under test?
To exclude any method from the code coverage you can use the [ExcludeFromCodeCoverageAttribute]. I believe that NCrunch will honor this attribute.
You can also use comments to exclude code from code coverage. Details are explained in the documentation. How it works:
NCrunch recognises 3 different types of coverage suppression comments:
//ncrunch: no coverage start - Marks the beginning of a block of code with code coverage suppression.
//ncrunch: no coverage end - Marks the end of a block of code with code coverage suppression.
//ncrunch: no coverage - Marks an individual line of code for code coverage suppression (place at the end of the line).
When working with a language other than C#, simply replace the '//' comment syntax with a syntax that is specific to your language.
I would question why you want to exclude private methods from the code coverage calculation though? surely they are methods in your class that need testing?
EDIT
Just because your methods are private it doesn't mean that they should not be covered by your tests. Your tests should be testing either the external behaviour of your class (when I give these inputs I get these outputs) or the internal interactions of you class with its dependencies (when I call this method with these values my class calls this method of its dependent object). The fact that some methods on your class are private is an irrelevant implementation detail. If your tests call your class but cannot exercise your private methods then this is likely an indicator of some other issue with your class, like it is doing too much.
Do you have a real example of the private methods that you want to exclude from code coverage, maybe we can help see if there is some other issue at play here.
Related
Is there a way to test private/ protected methods in JUnit5?
In JUnit 4 testing private methods may be an indication that those methods should be moved into another class to promote reusability. And for protected methods tests should be placed in the same package as the classes under test.
What is the case in JUnit5?
In JUnit 4 testing private methods may be an indication that those methods should be moved into another class to promote reusability.
I’d argue that this statement holds without the first three words. There’s no difference between JUnit 4 and 5 in this regard; even more, the testing framework has nothing to do with it at all.
So I recommend that you proceed equally: Either test the private method indirectly through the public interface or extract it to a place where it can be exercised independently.
I have been writing so OO VBA code, it really helps me to write frequent unit test.
My approach to writing these tests would involve writing a Sub names 'test_CLASSNAME' in there I woudl instantiate my object, set parameters, and concludee with Debug.Assert.
Problem is my classes are getting bit more complicated now and I would like to run unit tests that involve Private methods & properties of the class. Using my apprach that is ofcourse not possible because I am using an external Sub to call relevant methods.
So my question is what other approaches exist to Unit testing in VBA, preferablyu ones that manage to access private methods of a class?
I came across follwing post but solutions involved installing add-ons my work policy forbids from doing that. So I was specualting that if I could create a test subclass of the class I want to be tested I could access all internal stuff( This is for example how Ruby solves this using Module Test::Unit).
For Argument Sake here is a dummy Class that I want to test
Class Dummy
Private Priv1 as Integer
Private Class_Init()
Priv1 = 1
End Sub
Private Sub sub1()
Priv1 = 2
End Sub
End
And Here is How I would normally test this(Provided my method, and property was not private,thus in this case this is invalid):
Sub test_Dummy()
Dim tested as New Dummy
Debug.Assert tested.Priv1 = 1
tested.sub1
Debug.Assert tested.Priv1 = 2
Debug.Print "Dummy passed all tests"
End
The Rubberduck project started with the porting to C# of some VBA unit-testing code which you can find right here on Code Review Stack Exchange - it won't let you call Private methods, but if you can't install any IDE add-ins your best bet is probably to write your own.
I'm not going to detail everything here, but I encourage you to take a look at the Code Review post I just linked to (and the other related CR posts, too) and to implement your own version of it.
As for testing Private methods... don't do that. They're implementation details, at a lower abstraction level than what you're really testing. Test the Public methods that call them - if these methods work as they should, then the private methods are doing their job.
I found, that when I writing unit tests, especially for methods who do not return the value, I mostly write tests in white box testing manner. I could use reflection to read private data to check is it in the proper state after method execution, etc...
this approach has a lot of limitation, most important of which is
You need to change your tests if you rework method, even is API stay
the same
It's wrong from information hiding (encapsulation) point of view -
tests is a good documentation for our code, so person who will read
it could get some unnecessary info about implementation
But, if method do not return a value and operate with private data, so it's start's very hard (almost impossible) to test like with a black-box testing paradigm.
So, any ideas for a good solution in that problem?
White box testing means that you necessarily have to pull some of the wiring out on the table to hook up your instruments. Stuff I've found helpful:
1) One monolithic sequence of code, that I inherited and didn't want to rewrite, I was able to instrument by putting a state class variable into, and then setting the state as each step passed. Then I tested with different data and matched up the expected state with the actual state.
2) Create mocks for any method calls of your method under test. Check to see that the mock was called as expected.
3) Make needed properties into protected instead of private, and create a sub-class that I actually tested. The sub-class allowed me to inspect the state.
I could use reflection to read private data to check is it in the proper state after method execution
This can really be a great problem for maintenance of your test suite
in .Net instead you could use internal access modifier, so you could use the InternalsVisibleToAttribute in your class library to make your internal types visible to your unit test project.
The internal keyword is an access modifier for types and type members. Internal types or members are accessible only within files in the same assembly
This will not resolve every testing difficulty, but can help
Reference
I have looked at other discussions about this topic (on StackOverflow) however the other questions seem to be language specific whereas this is not language specific and I'm considering no longer using private methods, classes, and modules.
I want to test my private methods, classes, and modules so that I can more easily locate bugs. To allow me to do this I'm considering no longer using private methods, classes, and modules for two reasons, (1) I see no reasonable way of testing a private method, class, or module without injecting test code or using some sort of "magic" and (2) to improve code reuse. Note that I'm not considering no longer using private variables and properties because data needs protecting and does not provide behaviour therefore it does not need to be public during testing.
As a lame example, if you're writing a module called OneOperations that has two public methods addOne and subtractOne, and two private methods add and subtract. If you were not allowing yourself to have private methods you would put the two private methods into another module (basicOperations) where they are public and import those methods inside the OneOperations module. From this you should now be able to write testing code for all the methods in both modules without injecting code. An advantage of this is that the methods add and subtract can now be used in other modules by importing the basicOperations module (2 - improving code reuse).
I have a feeling this a bad idea, but I lack the real world experience to justify not doing this, which is why I've posted this question on StackOverflow.
So, how do you test your private methods, classes, and modules? Is not writing private methods, modules, and classes a potential solution?
1) Like in many other answers on this topic, the main question is why would you want to test your private methods? The purpose of a class is to provide some functionality to its clients. If you have comprehensive unit tests that prove that the public interface of this class behaves correctly, why do you care what it's doing in its private methods?
2) Your idea of not having private methods at all seems like cutting your leg off. For small projects it may be possible to have every tiny behaviour well separated and tested. But for large projects it's an overkill. What matters, is the domain logic behaving correctly.
Consider for example a method:
public double getDistanceSquared(Point other)
{
return getDifferenceSquared(this.x, other.x)
+ getDifferenceSquared(this.y, other.y);
}
private double getDifferenceSquared(double v1, double v2)
{
return (v1 - v2)*(v1 - v2);
}
Ad1) Does it really make sense to unit test getDifferenceSquared method, if getDistanceSquared returns correct results for all test cases?
Ad2) Creating a separate class for calculating squared distance between doubles - in case there is only one place when it'll be used leads to a swarm of tiny classes, with millions of tests. Also, constructors of your domain classes will accept like 10 different interfaces for every tiny thing they're doing internally.
Maintaining all this is a lot of unnecessary work. Imagine that you would like to change the method of calculating the distance (maybe use some precomputed values). The behaviour of getDistanceSquared would not change. But you would have to change all of the tests of getDifferenceSquared even though you shouldn't have to care how is the distance being calculated, as long as it's calculated correctly.
Diving into minor details when it's not necessary makes you forgot what you're really doing - you lose the "big picture view". Value your time, and focus on important problems.
As a side note, also - the main concern of unit tests is not "locating bugs" as you suggest. They impose a clean design, provide an always up-to-date documentation of your code's behaviour and allow convenient refactoring giving you flexibility. Additionally they assure you that the code is working as you expect it to.
http://artofunittesting.com/definition-of-a-unit-test/
http://en.wikipedia.org/wiki/Unit_testing#Benefits
There is another way to look at this, which is how do you generate a private method?
If we are following the TDD process properly, then the first thing we write is the test. At this point the test should contain all of our code, e.g.
public void ShouldAddTwoNumbers()
{
(1 + 1).ShouldEqual(2);
}
Yes, that looks appalling. But consider what happens as we write is some more tests.
public void ShouldAddTwoMoreNumbers()
{
(2 + 2).ShouldEqual(4);
}
Now we have something to reactor, so it can become
public void ShouldAddTwoNumbers()
{
Add(1, 1).ShouldEqual(2);
}
public void ShouldAddTwoMoreNumbers()
{
Add(2, 2).ShouldEqual(4);
}
private int Add(int a, int b)
{
return a+b;
}
So now we have a private method that we can test inside our test class. It's only when you complete further refactoring to move the code out into your application, that the private becomes an issue. Most automated refactoring tools will offer you the option of changing the methods signature at this point, so that the private method is still accessible, because its not private.
(There is a fabulous exercise called TDD as if you mean it by Keith Braithwaite which I've just paraphrased above)
However, this isn't the end of our refactorings and development. One thing that we should be doing as we write and refactor our tests is to delete old tests, for example when functionality is duplicated. Another is to extract new methods so we don't repeat ourselves. Both of these can lead to scenarios where we have private methods back in the non-test code base.
So my advice is to be pragmatic, make the best decision you can for the code that you have in front of you. I wouldn't advise not creating private methods, but I would instead look at the factors that lead you to create them.
I decided to add unit tests to existing project (quite big one).
I am using "google toolbox for mac" for various type of STAssert... and OCMock framework.
But I think I'm testing wrong. For example, I have public function saveData, which doesn't return anything and only change internal state of the object. Should I test it? Due to encapsulation principle - I don't have to worry much about object implementation and I mustn't depend on private variables (because they can change/be deleted in the future)
#implementation Foo
-(void) saveData {
internalData_ = 88;
}
In real project this function saveData is 100 lines long and it's change a lot of private variables of the class.
So, should I test it or not? I have a little previous experience in unit testing and cannot make decision by my own.
Does the internal state that gets changed affect any later calls on that object? If so, you should include it in a unit test like
Test a()
Do saveData()
Test a() again
Even if not, it might be a good idea to unit test it. Not for determining whether other code will break by using this method, but for automatically testing the correct implementation of the method. Even though the method doesn't return anything, it probably still has some kind of contract ("If I call it, this must happen") and you should check if what should've happened, happened (e.g. a line added in a log file, or something).
Now, how to check that if the method doesn't return anything, is another question entirely. Ironically enough, that's an implementation detail of the unit test.