Honestly, the point of this article is influence you to glance at my open source tool that blows up and errors on the first file within a folder that doesn't match any of a given list of glob patterns. (It enforces folder structure.)
I walked into a new project and I didn't know where to put anything. I was lightly involved from the beginning, but was planning to get my hands very dirty now.
There was a defined folder structure and I knew it. Heck, I understood all the folder structures. There were 3, the dominant original, one in which I implemented a past feature in, and the new structure the new lead wanted. In the newest "desired" structure files either contained things referenced once/twice, or instead things referenced throughout the app.
There was only 1 problem with the existing structure, if I extracted small units of code they didn't belong anywhere. The lead didn't want a place for them to live. But that made my job a lot harder.
My scripts were designed to hone in on files I thought needed unit tests the most. Both the easy ones with few conditionals that a inexperienced dev could throw themselves into, and the hairiest ones with the most conditionals a senior dev would need to pick apart.
The problem was that the scripts worked best when I could separate out a unit, re-run the script, and move past that unit to the next candidate if the script no longer thought it the most pressing unit to test. So I had to refactor my script to weigh files differently to match the messier world I was now living in. That actually wasn't too bad as I was able to tune it over time.
The lasting negative was that I had to read large files from top to bottom and count missing lines of coverage manually to find the largest unit to break out into, not a new file, but the existing one. Facepalm. I didn't have the respect and audience to gain the traction needed to break units into smaller files, and the folder structure didn't allow it. It was too simplistic and allowing every new unit to form a new file would bloat the directories.
So I'm finally getting to my opinionated point. All folder/file structures should have top level folders that silo files. When a folder gets to have too many files, you should be able to extract out files into a new folder. You should be able to have as many top level folders as you want and strike a balance of not too many files per folder or too many folders. But, you should never stop a single function from living alone in it's own isolated file.
And if my reason for wanting to break out smaller individual functions into there own individual files doesn't resonate with you, there are more reasons. Unit test file names usually correlate to app file names and if the files contain more than one unit, the corresponding test files blow up in size.
Having more than a single unit per test file can also complicate tests where mocked imports and spies for one unit complicate writing tests for all other units. Testing only one unit per unit test file greatly simplifies testing. Splitting out individual units into separate app files also simplifies spying on them. Otherwise, things get can get ugly hacky with circular imports.
I guess I'm done writing. I'll eventually try to open source a version of the scripts I run to suggest the next unit test you can write.
Top comments (0)