Story of non-testable code

At my company, we have a library that allows us to read data from a content management server.  The library will check for new content periodically.  This allows us to make content changes (change the label on a button or the legal disclaimers on the bottom of the page) without going through a full code elevation.  We just change the content in the CMS and the JVMs automatically pick up the content change.

This library was not implemented in a testable way, however.  Instead of being a Spring bean, or a singleton, or another of a hundred other ways, the developers show to make it a static class.  The class has all static methods.  We can still technically mock the class; we just need to use a tool like PowerMock.  This class is used all over the place, so what should be simple unit tests end up containing dozens of lines of mock statements.

I was tasked to make a change to a REST call.  The change needed to be made, but it was a very risky change.  I decided to heavily unit test the REST call to make sure my change didn't break anything.  If the content library was written in a testable way, I would have the opportunity to create my own implementation of it.  In that implementation, I would return the content chunks I care about, and ignore the content chunks I don't care about.  Instead, the code was written statically.  I had to use PowerMock to mock out every single time that REST call called the content system.  I cared about 3 pieces of content.  I had to mock out 30 pieces of content, per unit test.  I had 27 test cases.  I put all the mocking for the content I don't care about in a common method that each test case could call.  This isn't the worst part of the situation though.

A few weeks later, someone else had to make changes to the same REST call.  Their changes had nothing to do with my changes.  The build broke because my unit tests were failing.  The unit tests didn't actually find a problem.  What they found was new content being requested that the mocking system didn't know about.  This is why so many developers hate unit tests.  This particular developer spent more time trying to fix my unit test than writing the code they were supposed to make.  This gave me a bad reputation because I'm the guy who wrote the crappy unit test.

Fast forward even more and another developer is making changes to the same REST call.  This time they are making changes in the code that I made changes in.  Once again the unit tests fail.  This time, they fail for two reasons: 1) new content and 2) a regression was introduced.  Since these unit tests have a reputation for being brittle and the developer didn't want to deal with unit tests that give false positives, he removed the unit tests.  This was a major regression that would have cost lots of money to fix if it made its way into production.  Luckily it was caught in manual testing.

Automated unit testing can be a wonderful thing.  It can save lots of money.  There is a big but, though.  It can only do those things when it is done right.  Forcing the wrong type of unit testing makes the situation worse.

Build all the things! (and wait for it to fail)

Continuous integration is a great concept.  Within a few minutes of making a change, you can get quick feedback about potential problems with your change.  You can run unit tests, which helps spot problems internal to your module.  You can run integration tests, which helps find problems between your module and any modules you depend on.  You can run static code analysis to attempt to find bugs in your code.  How about code complexity analysis, or dependency analysis, or a build violations checker.  Well, as long as those run fast, I guess, maybe.  How about installing your war file into Tomcat, starting up a browser and running a browser automation tool to validate that it still works.  Hmm....this is starting to be a lot.  What ever happened to quick feedback?

Oh, you want quick feedback?  Then we can just at a time limit to your Jenkins job, so if it runs more than 9 minutes, then your job fails?  How about that for quick feedback!  Well, if my jobs are going to fail because too much is running during the builds, I can just reduce what runs in those builds.  Brilliant!  What....I don't actually have access to reduce the number of things that occur during the build?  The team that mandated that builds fail after 9 minutes is the same team that mandates that all those build steps must be done?  The same team that gives us a Jenkins instance that 10 executors and a backlog of 60+ items at all times?

When you try to measure everything, you end up measuring nothing.  This is my life.

EInk on a phone. Maybe with Project Ara

I have been talking about EInk with a buddy of mine for months.  I want a phone that supports an EInk display.  Obviously an EInk display will not work 100% of the time, but if you could hot-swap the screen.....like with Project Ara....then you could have an awesome set.  This topic was recently brought up on reddit.  I am not the only crazy one that wants an EInk display for a phone.

I see two major benefits for having an optional EInk screen on a phone.  The first is battery life.  Out of all the components in your phone (antenna, process, RAM) your screen takes up the most battery.  EInk displays only require battery when the contents of the screen change.  This is why they are great for e-Books.  You spend a little electricity to change the screen to display words.  Once the words are visible, the screen no longer draws electricity.  If you have an EInk display on your phone, then turning on your screen is no longer a big deal.  You obviously can't play games, but it is good enough for email, SMS and phone calls.

The second major benefit is using your phone outside in the daylight.  LED displays are sometimes hard to see in sunlight.  You often have to bump up the brightness just so you can see the screen, taking up even more battery.  With an EInk display, you can use your phone outside again!

The question becomes how do you put an EInk display into a phone.  The Yota Phone 2 puts an EInk display on the back of the phone, so all you have to do is spin the phone and switch which display gets used.  There was a Kickstarter for a second screen that attaches to your phone.  This screen is awkward and not very compatible.  I think the best bet is with Project Ara.  With Project Ara, you could in theory hotswap the screen with one that uses EInk.  I can't wait for Project Ara to be released.