Why I avoid using verify in tests

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.

Continue reading “Why I avoid using verify in tests”

The Operations Developer

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 FacingMobile, 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.

Continue reading “The Operations Developer”