0

The project (Java/Spring) I currently work on has a rather large unit-test class for one of its services : more than 1000 lines, several Nested class (one per big functionality), some tests without a Nested class, ...

Finding this file rather difficult to read, and to manage (a modification in the service, and you have to take time to find the corrects tests to fix/update), I proposed to split the class to have one test file per Nested Class, each one linked to a "principal" test file, which will be managing the Mock & the tests without Nested Class. All the tests files would be put into a specific package.

I am wondering if this would be a good thing to do? or if it was something to avoid to do ?

I hope i was clear enough. Have a nice day

6
  • 1
    Anecdotally, I'd say that your nested classes are the problem, not the unit test class. But the principle behind your proposal is sound. Gary Bernhardt (of "Destroy All Software" fame) calls it the "Squish Principle," which basically means "smaller classes make better architecture." Commented Oct 22, 2020 at 15:14
  • Yeah - because you have unit tests for the service, you should be able to decompose the service itself into something more manageable. You may be able to do this with relative ease, or you may need to do it step by step if the tests know too much about the internals, but either way, the tests are a safety net. As you decompose the service, the tests class should split as well. Commented Oct 22, 2020 at 16:31
  • 1
    Ask your team, if necessary. If you can decide alone, try it out. If a 1000 lines file is hard or easy to handle, and if several files are simpler to manage, depends a lot on your development environment / IDE.
    – Doc Brown
    Commented Oct 22, 2020 at 17:31
  • @DocBrown: Are you suggesting "code folding?" Because I can point you to a whole bunch of people that are adamantly against the use of #region. Not saying I agree with them, just sayin'. Commented Oct 22, 2020 at 18:51
  • @RobertHarvey: no, I am not suggesting any special feature. But I am pretty sure some Java IDEs will allow to list or navigate between nested classes (or methods of those classes) in a single file better than others. What I am suggesting is talking to the team, and trying out what works best in the OPs environment.
    – Doc Brown
    Commented Oct 22, 2020 at 22:32

1 Answer 1

8

I do not care about the nested classes. I care about being forced to look at things that don’t matter. Tell me one story at a time.

The whole point of not putting all the code in one file is that the stuff I have to think about now is in one place and stuff I don’t need to see now hides in some other file. Oh sure, you can mash it all into one file and watch it grow but just because it still compiles doesn’t mean that’s a good idea.

Organize code for humans. We like short, pointed stories about few subjects. Not thousand line odyssey’s about every possible thing that can be crammed into this particular file.

But, before I let you break up that file you have to solve one of the hardest problems in computer science: you have to think of good names.

You can cause an even bigger mess by breaking this up with poor names. Names are how I find this stuff. Give me good names, names that don’t surprise me when I look inside, names that help me find what I’m looking for. You can break it up as finely as the compiler will let you. Because I just need the parts of the story that matter to me. I don’t need every also-ran.

Pay some heed to the current organization of the code, of course. Using a better style won’t shine if it drastically clashes with the current style. How you feel while breaking up the code isn’t important. It’s how you’re making the next poor coder feel.

So talk with your team. Tell them the names you have in mind. Show them how it would look. See what they think. Be sure the pain you save them from is worse than the pain you cause.

25
  • 1
    @RobertHarvey in my experience the single greatest limiting factor of code organization is vocabulary. Breaking down code requires good names. Thinking of and testing good names is real work. Ignoring this always makes a mess. Commented Oct 22, 2020 at 19:36
  • 2
    Sure, but limiting the scope of the code you have to look at at one time greatly moderates that problem, even if you have bad names. I can always fix the names; the IDE even helps me to do that. Refactoring a big method is a bit harder. Commented Oct 22, 2020 at 19:37
  • 1
    If only we could make names that actually accomplish that. Fortunately, there are always comments. Commented Oct 22, 2020 at 19:41
  • 1
    Basically, Uncle Bob Clean Code simple. Commented Oct 22, 2020 at 19:46
  • 1
    @RobertHarvey & candied_orange: from what I gathered, people often get told to "follow established conventions and project structure & best practices", which is, on the face of it, fine, but due to lack of context (perhaps because of lack of communication), combined with lack of design skills, in practice this too often translates into (1) applying "best practices" religiously, and (2) emulation, via copy & alter, of existing code, resulting in duplication of what could be extracted into a separate abstraction (an organizing object of some sort, a helper class, whatever). 1/2 Commented Oct 22, 2020 at 20:29

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.