• Liked George Dinwiddie

    Evolutionary Anatomy of Test Automation Code

    George Dinwiddie
    George Dinwiddie
    schedule 4 months ago
    Sold Out!
    90 mins

    Many people agree that one important outcome of Behavior Driven Development is a set of regression tests to demonstrate the desired behavior and ensure that it is maintained over time. Then they often struggle to do so in a manner that remains maintainable as the system and the test code grows larger. Sometimes they even abandon their tests and start over, repeatedly.

    In this session we'll examine the evolutionary history of an application and its test suite. We'll stop at various stages in its life to consider the choices we might make to address growing complexity.

    We'll work using Cucumber-JVM and Java in order to be accessible to a large audience. You can apply these concepts in other languages and test frameworks. Rather than depending on having enough laptops set up, we'll use mob programming to enable everyone's participation.

    If you'd prefer exploring on your own machine, bring your laptop loaded and ready to go.  Clone the code repository from https://github.com/gdinwiddie/EquineHoroscope to get the code and its history.  Unzip http://idiacomputing.com/pub/EquineHoroscopeJars.zip in the same directory for the dependencies.  (Download sample at https://leanpub.com/EvolutionaryAnatomy/ for even more detailed instructions.) I'll be using Eclipse, and the instructions are tuned for that, but you can use any Java IDE.

    Bonus: Participants will receive a coupon for a free e-book on the material.

  • Liked David Laribee

    Testing Strategy: New Model, Better Outcome

    David Laribee
    David Laribee
    schedule 5 months ago
    Sold Out!
    45 mins

    Pyramids? Quadrants? Cupcakes?! There are a wide array of models that describe approaches to test automation strategy and their possible positive (or negative) outcomes.

    In this talk, we’ll survey the landscape of testing models: models that range from technical to product to cultural mindsets, including best practices and anti-patterns. I’ll add detail and nuance to each of these models in the form of professional experience, real world example, and case study. 

    With a new lens, focusing on testing strategy as an act of curation, I'll share a new approach to evolving a testing strategy appropriate for your product development team's specific context.

  • Naresh Jain
    Naresh Jain
    schedule 2 months ago
    Sold Out!
    45 mins
    Experience Report

    By working with some of the most successful tech-product companies, I realised that code is NOT an asset, it's a liability. We should strive hard to minimise code. In 2011, when I started to hack on ConfEngine, I questioned my belief in TDD. I had also started playing around with APL style Array-Programming and Functional Programming. I felt, may be, I was getting a bit too dogmatic about TDD and automated tests in-general. As a thought experiment, I decided to build ConfEngine without ANY automated test. At first, it was really scary not to have the safety-net of automated test (something I took for granted for almost a decade.)

    As I scaled ConfEngine without any automated tests, I had certain interesting realisations:

    • How to embrace Simplicity and Minimalism WITHOUT automated tests
    • Why Throwing Away Code frequently helps you achieve a better decoupled-design and how this helps in better experimentation
    • Fear of Refactoring WITHOUT Tests is over-rated (Good IDE and safe-refactoring techniques can take you a long way)

    ConfEngine grew from a pet-project to a 8 member product team. It has over 60K users and has done financial transactions worth over half-million USD. And we continue to push forward without ANY automated tests. Its not perfect, but it has certainly helped me challenge my dogma around TDD.

    Background: In 2001, I stumbled upon the Test Infected paper. For the next 2 years, I struggled to really apply the test-first concept on real projects. Finally in 2003, I felt that I had fully internalised TDD and was able to apply on almost all projects. Then I started playing around with FIT and FitNesse, using ATDD on some of the projects. In 2006 I published "Avatars of TDD" paper in which I explained various styles of TDD and its design implications. Until 2011, I was a very big advocate of TDD, ATDD and BDD. I still like those practices, however I would not recommend it in all projects.

Sorry, no proposals found under this section.