Five for Friday – January 12, 2018
- I’m finally reading Pat Lencioni’s latest book on Ideal Teams. I’m a huge fan of Pat Lencioni’s business novels, and enjoying this one just as much as the others.
- You’ve probably already seen this article on testing microservices. I shared it with my team this week, and think it’s a good read.
- All About Lean has an article on The Toyota Employee Evaluation System. Some good stuff there, and some stuff to ignore. As an aside, I so do not miss the msft annual review process.
- A few months ago, I mentioned the neuroma in my left foot. To give my foot an even better chance of lasting longer running distances, I recently switched to Altra running shoes. Altra’s have two unique features: a wide toe box (to give my toes more room to spread out and not pinch the nerve; and a “zero drop” – meaning that the heel and toe are at the same level. So far, they’ve been fantastic.
- The 2018 State of Testing survey is out. While I’m not often a fan of these surveys (too much room for bias in the interpretation for me), this one is the best one, and the only one I take and read about. If you haven’t filled it out already, go ahead and give it a shot.
I remember ranting to a friend about parts of that microservice post. Is that what you meant by “good read?” My favorite fallacy was calling the notion of running the stack on one box a fallacy because nobody cared about their Vagrant setup enough to use it. That seemed to indicate that nobody cared about integration testing. Probably because it was going to be owned by a yet-to-be-hired tester.
And that was not the only example of misguided finger pointing in the article. Scanning it now, I know that I was upset by misunderstanding why VCR is used* and I could swear there were at least a couple of other glaring problems. Worse, it popped up on Hacker News, so it served to misinform a bunch of young programmers without much testing experience. *grumble*
* VCR is Ruby code that does record/playback over HTTP. VCR tests are really useful for determining when a code change has made an unexpected change in a result. It has a bunch of other fancy/handy features but really it’s only about finding out that your code change somehow ended up interacting with some other service differently. And that’s pretty useful, imho.