Comments on: Test Driven Development: Testing Private Methods Using Aspect Oriented Programming

By: Nick

Nick — Tue, 07 Sep 2010 15:36:12 +0000

Check out Powermock. It is a testing library that allows you to call private methods directly. You can do a lot of stuff such as set/get private memebers without setter/getters.

By: JNovice

JNovice — Tue, 31 Aug 2010 13:42:43 +0000

Hi,

Nice post and great discussion. While I have been using reflection to great effect for testing private methods so far, I have hit a road-block with testing private methods when the source code undergoes obfuscation. I tried this method and it works really well for me. While I understand that testing private methods is like breaking encapsulation and not in keeping with the design, there are some places where you would want to do this.

Thanks for the nice article

By: Khaled Hussein

Khaled Hussein — Fri, 03 Apr 2009 18:47:41 +0000

Tomek,
Thanks for you comment. I agree with you that there are plenty of solutions (hacks) to this problem. So, you can think of this one as yet another solution that leverages relatively new technologies such as Aspect Oriented Programming.

As comparing it to reflection, I don’t think that reflection is any simpler. However, I have to say that reflection gives you one of the same advantages which is testing private methods without adding any code to your code base. Yet in both cases, tests will be clear to understand and so forth — maybe not as clear as other approaches.

Side note: I don’t think that because there aren’t that many developers that know AspectJ, we should ignore what AspectJ can do for us .

I am just sharing my basic knowledge and some of my thought.

By: online gambling history

online gambling history — Sat, 28 Mar 2009 07:08:04 +0000

How to test private methods? This question comes up a lot but I just don’t get it. What test drove you to write a private method in the first place? In my experience private methods pop out of the re factoring stage and are adequately covered by the existing tests. Of course at some point in the future a test I write might need the functionality in that private method, at that point it will get hoisted in to the public interface of some class and have appropriate tests.The question is what private methods to test? I have had a lot of answers to this question and all of them boil to that we should test private methods that have more than one path of execution and we need to test different paths, private methods that are complex enough not to be covered by one test scenario, and private methods that may or may not be executed by public ones. I normally only end up with private methods that are there for code clarity/duplication removal reasons. These are exercised perfectly by the tests that test the behavior of the class under test. All others tend to migrate into the public interface of some other class and become easy to test..I am hoping the same best work from you in the future as well.In fact your creative writing abilities has inspired me to start my own word press blog now. Really the blogging is spreading its wings rapidly.Your write up is a fin example of it.

By: Tomek

Tomek — Mon, 01 Dec 2008 21:45:46 +0000

Khaled, the web is full of descriptions on how to test private methods in java, and the solutions (e.g. reflection API) are much simpler than using AspectJ (how many developers know AspectJ ? how many will understand your tests ? IMHO simplicity of test code is crucial), so why bother with such a big cannon here ? I don’t understand why you propose such a weird solution with no real advantage over other existing ones.

Tomek

By: seo blog

seo blog — Tue, 28 Oct 2008 13:40:44 +0000

This is a really interesting blog post,I have added your blog to my bookmarks I really like it,keep up the good work!

By: Brian Genisio

Brian Genisio — Wed, 22 Oct 2008 02:01:18 +0000

I agree with the anti-private testing camp. There are ways in .NET to use reflection to gain access to privates which are pretty slick. In almost all cases (except for cases where driving the GUI is involved), I consider this to be bad practice.

If there is code in a private that a public method cannot hit via a unit test, it is probably dead code and should be removed. If that code is necessary, but you can’t test it, then you probably need to re-think your design.

Unit tests, in my opinion, are used to test and hold up the design of the code you are testing. Your assumptions and requirements for the unit are baked directly into the tests. They test behavior and privates do not expose behavior… publics do. In TDD, privates are just refactorings of the public behavior.

I have been doing TDD for over a year now, and I have been successful in writing full test suites for units without testing privates.

I agree, it is a matter of philosophy… a debate that needs to keep happening. Without it, we will remain stagnant.

Cheers!

By: Jacob

Jacob — Fri, 03 Oct 2008 13:23:13 +0000

In Java at least, there are multiple implementations you can find of a PrivateAccessor class that can modify private fields and invoke private methods on an object.

The biggest issue I have is that you normally don’t test drive private methods at all. You are testing the behavior of your object and that behavior is defined by the public parts of that object. Basically, you write a test (red), you implement it (green), and then you remove duplication or increase clarity by pulling parts of your public methods out to private ones (refactor).

By: Clark

Clark — Thu, 02 Oct 2008 14:10:43 +0000

I think what both Michael Feathers and I are trying to say is that testing a private method is only treating a symptom of the real problem, we should be fixing the real problem i.e. the lack of cohesion in the design.

By: Khaled Hussein

Khaled Hussein — Thu, 02 Oct 2008 13:27:30 +0000

Martin,

As for Michael Feather’s article, I think it is interesting. However, I think that “your design will improve if you aim for testability” is something that we all know and agree upon once you start using TDD . Right? The only problem is that your design improves over longer periods of time, which is debatable and out of scope. The scope of my post is to show you a new tool to use for testing private method if you need to.

I’d like also to expand our vision here to multiple purposes behind unit testing. For example, code coverage in which you might need to unit test specific paths in private methods.

Note: I don’t regret things easily (if ever) . We learn from our experiences and from nice people like you sharing their thoughts .