Java Magazine, Nov/Dec 2016

ORACLE COM JAVAMAGAZINE NOVEMBER DECEMBER 2016 37 junit 5 that the amount of testing thats applied to that code before that ever gets checked into the main build is probably significantly greater than at typical business sites Is that true too Beck That is not true as a blanket statement Theres a principle I learned from an economics professor called reversibility Say you have a complicated system that reacts unpredictably to stimuli Henry Ford built these unprecedentedly large factories complicated systems in which a tiny little change could have huge efects So his response to that was to reduce the number of states the factory could be in by for example making all cars black All cars werent black because Henry Ford was a controlling tightwad It was simply so that the paint shop either had paint or it didnt That made the whole thing easier to manage Well Facebook cant reduce the number of states Facebook is in We want to keep adding more and more states Thats how we connect the world So instead of reducing the number of states we make decisions reversible In Henry Fords factory once you cut a piece of metal you cant uncut it Well we do the equivalent of that all the time at Facebook If you make a decision reversible then you dont need to test it with the kind of rigor that youre talking about You need to pay attention when it rolls out and turn it of if it causes problems Binstock Thats an interesting alternative approach Beck Well theres a bunch of counterexamples For example code that handles money does go through extraordinary rigor or the Linux kernel goes through extraordinary rigor because its going to be deployed on hundreds of thousands of machines But changes to the website you get feedback lots of different ways You get feedback by testing it manually you get feedback by using it internally You get feedback by rolling it to a small percentage of the servers and then watching the metrics and if something goes haywire then you just turn it of Binstock So nonreversible decisions get the heavy rigor and perhaps extreme testing and everything else rides much more lightly in the saddle because of the reversibility Beck Yes Development of JUnit Binstock Lets discuss the origins of JUnit This has been documented a lot in various videos that youve made So rather than go through it again let me ask a few questions How was the work initially divided between you and Erich Gamma Beck We pair programmed everything Binstock So you guys were both involved throughout the entire project Beck We literally did not touch the code unless we were both sitting together for several years Binstock Were you using a form of TDD at the time Beck Yes strictly We never added a feature without a broken test case Binstock OK So how did you run the tests prior to JUnit being able to run tests Beck By bootstrapping It looked ugly at first You might be working from the command line and then very quickly you get enough functionality that it becomes convenient to run the tests Then every once in a while you break things in a way that gives you a false positive result and then you say All the tests are passing but were not running any tests because of whatever change we just made Then you have to go back to bootstrapping People should try that exer Tests are just one form of feedback and there are some really good things about them but depending on the situation youre in there can also be some very substantial costs