I am asking in case I run into this scenario in the future.

Someone in my company wrote multiple methods with 25 parameters. I don't know how/why it got thru code review. I'm just wondering how someone would write unit test cases in junit for this? The number of combinations/permutations would be crazy.

I know the real solution is to rewrite/refactor the methods to do less but I don't think this team plans to do this for now. If I were the poor test engineer assigned to write automated unit tests for this, how would one go about this?

  • Does it happen often? In rare occasions, 25 or more parameters can be accepted. It depends on its context.
    – Yu Zhang
    Jul 13, 2018 at 23:20
  • @YuZhang, This has happened repeatedly with this one developer at my company. For some reason, the manager of the group is pushing them to release as quickly as possible at the expense of technical debt. I see this happening and I'm just waiting for the day that the piper needs to be paid. I haven't worked that long so I don't know of other occurrences but I wouldn't doubt that this happens more often then not, especially when people are under pressure to release things quickly and often.
    – Classified
    Jul 14, 2018 at 4:45
  • What is the production issues state of such application? Are they normal or comes more often with showstopper issues? Jul 14, 2018 at 14:02
  • These stats will not be a direct answer to your question but might be helpful in opening eyes of the decision makers. Jul 14, 2018 at 14:03

5 Answers 5


If refactoring is not an option then try to see this big function as a class of methods and focus on individual parts of this function which themselves are a logical entity, and design parameters values accordingly keeping all the other irrelevant parameters values as static.


I can't think of a developer writing a method which takes 25 arguments. This is a terrible design. Practically your method should not take more than 3 arguments.

OK, coming to a solution, in case you encounter something terrible like this; how to test it:

  1. Ask the developer to refactor that method so that it becomes testable. I'm not kidding.
  2. Instead of passing n number of arguments pass an Object which has all those attributes.

The method definition below

public void myMethod(int a, String b, Map c, ...........){}

must be replaced by

public void myMethod(ParamObject po){}

Writing unit tests for the refactored method would not be a problem.

  • Yeah, I don't know how good a developer this person is. This person just writes code to get things done at the expense of racking up technical debt, like this case where it's hard to test and hard to verify nothing was broken when new code is added. Unfortunately, the managers above aren't doing anything to force the team to follow best practices. In fact, I heard this person sends their code for code review but accepts the changes themselves and checks the code into the codebase.
    – Classified
    Jul 14, 2018 at 4:51
  • One time, I heard they checked in 1000+ lines of code for code review. The lead/architect complained that no one can review that but someone still continued doing that.
    – Classified
    Jul 14, 2018 at 4:54
  • 1
    It should be the responsibility of the development/engineering manager to have defined framework or guideline for writing cohesive and de-coupled code. Even I think a framework should not even allow anyone to write bad code. There would be loop holes, now it is up to how disciplined you are. Jul 14, 2018 at 9:02

A good approach would be to use a test Facade for each feature you need to test, this would provide a public API for the testing of that feature only, but supports and hides the full width of the underlying API being used. The implementation of the Facade would complete the fields unnecessary for your test but necessary for the underlying method calls to function.

Since you are responsible for Unit testing, you need to ensure this issue is raised by code reviews, a static analysis tool would provide solid metrics to support taking action here.


I guess most of the parameters can have some default value. You can always write a wrapper in your test code for the method that takes a parameter object and calls the original method. The parameter object constructor can initialise the fields to their default values. Now use this wrapper to write tests for the original method - each test setting only those parameters which are valid for the particular test.

You may ask the original developer to help in writing couple of tests - that might provide an incentive for refactoring :)


Use data driven-testing, either from a spreadsheet, or generate the test data from a program. (Which would be better depends upon the application domain.) I found these references (Wikipedia, guru99, and Microsoft)




Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.