When I first learned unit testing and Test Driven Development, test frameworks were very light and mocking frameworks were just coming into the picture. I was writing a lot of C++ back then, and if I wanted a mock I would implement my class interface and link my test to the mock version instead of the production version. Fast forward 15 years and we have extraordinarily advanced mocking frameworks (and I mostly write Java these days). While new libraries have come and gone, Mockito remains my favorite. It has a good balance of a straightforward syntax and a very complete feature set. In fact, a bit too complete if you ask me.
A big part of writing good automated tests is understanding why to write each test. While this seems obvious, people rarely think about it. When I write a test, I make sure that it achieves at least one of the following goals:
- Verify that the product meets the business requirements
- Give cover for future change
- Document intent
In an earlier post, I outlined why I think that there is value in enterprise developer specialization. I concluded that there are four emerging classes of developers: User Facing, Mobile, Business Logic and Data, and Operations.
In the past, operations was a separate role and often team working outside the development team. The DevOps movement led many developers to acquire operations skills and move that work back into the development cycle. When this amounted to a build-migrate-deploy cycle, it was reasonable for full-stack developers to do this work. Now, the operations landscape is sufficiently complex that a skill class has emerged. Operations Developers (and yes, they are developers) concern themselves with deployment scripts, infrastructure automation and cloud technologies. They do not maintain build scripts or Continuous Integration implementations; those are the domain of the other developer classes. Instead, they provide “infrastructure as a service” (IaaS) to the other developers and concern themselves with secure and stable scaling of that infrastructure. Puppet, Chef, AWS, Azure, OpenStack and Docker are some of the relevant technologies.
We’re failing our users when it comes to password management. Let’s resolve to do better!