Android Logger Refactor - Analysis
This is part 1 of a unknown number of posts going through a wrapper around android.util.Log that I use in a number of projects.
My favorite feature of this wrapper is being able to turn off logging while running tests. This particular iteration doesn't turn it off; but redirects it to System.out.
If you've done, or attempted, to unit test android code; the logging has probably blown up.
There are a lot of ways around this explosion. Robolectric was my fallback for the first three android testing frameworks I set up. It's excellent for existing app. Probably for greenfield apps as well. I look at this solution as a stop gap fix for bad coding practices. This applies to another tool I love and used extensively; PowerMock. These solutions help; often making it possible to; test code with dependencies on untest[ed|able] code. They do a great job at that. Fresh code shouldn't need them.
I say as I use Mockito 2's lab feature to strip Kotlin's non-open from classes.
In my weak defense, I'm also drifting away from unit tests and towards integration tests, but that's another post.
I think that's enough of a tangent for now. My log wrapper allows unit testing with a configurable logging so that logging can happen while writing/running unit tests.
The Fyzlog.java file is 317 lines, so I'll not embed it.
This file can be viewed in the FyzLog refactor gist.
Sibling to that file is the unit tests around it.
This logger grew over years into a fuller logging utility than the original log-on/log-off feature. It never was cleaned up... I never though it needed cleaning up. It was clean... until some training in Object Oriented Programming. Then the code was a crap fest I could practice on.
This post series is the result of that practice.
I don't feel where I got to is perfect, but it's better.
The next post is where we'll start refactoring; but here's a sneak peek at why I know it needs refactoring.
The logger has a glaring bit of duplicated code:
This if-else exists for all six of the logging levels. I could shove this into a single method; but this wasn't a code smell for me. Not at that time.
Now; an if is suspect. An if-else is probably wrong; while an if-elseif-else needs to be taken out back.
We have a smell, we have some simple code, sounds like a great refactor opportunity.
In part 2 we'll start refactoring the code and see where it goes.