• Getting started with Behat

  • Behat is a test framework for behavior-driven development (BDD) written in the PHP programming language.

    BDD is described by its creator, Dan North, as a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters. Whatever that means…

    Behat is intended to aid communication between developers, clients and other stakeholders during a software development process. It allows the clear documentation of testable examples of the software’s intended behaviour. Behat test scenarios are written with Gherkin, a business-readable domain-specific language following defined patterns.

    Don’t think of it as a tool for testing, in the sense of removing bugs, think of it as a tool for documentation and specification.

    Read More »

  • The journey to Microservices

  • We’ve come along way, even in the past few years. We’ve seen huge advances in web technology.

    We’ve all been there… It gets to the point where anything is better than the legacy code. Legacy code is any code without tests, that is understood by no one and is too fragile to change, even though the business demands more, the legacy code is impossible to maintain. It’s code that can’t scale and uses obsolete tech (PHP 5.5 anyone?).

    Moving away from the legacy code is always a challenge. Do you simply replace it with another monolith and say “no, we’ll definitely get it right this time”, or do you take a different approach?

    Read More »

  • Testing as code

  • In a time where DevOps culture demands “everything as code”, from infrastructure to monitoring, its about time we took “testing as code” seriously.

    First of all, I’m a big fan of test-driven design (TDD) and unit testing, but I’m not just talking about unit testing here. We already know unit testing should always done by a unit testing software framework, (usually) written before the code, and is always written in code.

    Beyond this type of functional testing, you venture into feature testing. Testing the integration layers, and end to end testing, probably manually. With automation as the goal, you really want to focus on how you approach testing and give some consistency across it all.

    There’s a number of principles and practices that lend support to the idea of this “testing as code” approach, including continuous integration, automation over documentation, automated testing, version control and infrastructure as code. Ultimately, it’s about making testing less painful.

    Read More »

  • Delivering Value

  • By now you’ve probably seen this image, with waterfall on the left, and continuous operations on the right, it’s an evolution.

    I’ve always thought that evolution was a great way to describe the software delivery journey of a company or team. Evolution is not about one person, it’s not about the first person being smart enough to discover fire. It’s about continuous improvement.

    It’s about values and attitudes, ideas and behaviours. It’s a way of thinking, a way of doing and a way of being. Culture, paradigms and philosophy. Practicing as well as preaching. It’s about taking the best experiences and sharing those with others. That’s how we evolve.

    There’s an Indian story about six blindfolded men who are trying to understand what an elephant is. One man just feels the trunk and thinks the elephant is a snake. The rest feel different parts and think that it’s a fan, rope, spear, wall, tree.

    The same can be true for us in software engineering. Often we find that we’re talking about the same thing but from a different perspective. Perhaps from a technological point of view (infrastructure, development or testing). Perhaps from a different methodology (Agile, Lean or Continuous Delivery). However they are all talking about the same thing.

    Read More »

  • Devops Best Practices

  • DevOps started out as “Agile Systems Administration”. In 2008, Andrew Shafer did a talk called “Agile Infrastucture” addressing issues around involving more of the company in the same disciplines as programmers.

    In 2009, Patrick Debois created “DevOpsDays” conference to help to bring it to light. However, it wouldn’t begin to trend until about 2010, when people would begin to describe it as a standalone discipline.

    Today, DevOps goes beyond just developers, systems administration and infrastructure, its about dev, ops, agile, cloud, open source and business, everything.

    DevOps is a movement. There’s no certificate, role, set of tools or prescriptive process. There’s no specification, it’s not a product, or job title. There’s no one true voice on what DevOps is or isn’t. It’s about attitude, ideas, customs and behaviours. Culture, paradigms and philosophy. It’s a way of thinking, a way of doing and a way of being. Practicing as well as preaching. It’s a conversation. It’s about taking the best experiences and sharing those with others.

    There are some very important qualities, principles and techniques that have proven to work, that everyone should be aware of, they are the best practices.

    Let’s explore those…

    Read More »

subscribe via RSS