Agile Buddha

Demystifying Agile, Getting to its Core

Testing

Introducing Mocktail: A Java Framework to Cache/Mock the External Dependency Response for Automated Tests

by Leave a Comment

Most of the software applications use interfacing points, e.g. a database, XML datasource, or a restful service. Such interfacing points pose challenges while creating repeatable automated tests. The challenges are as follows:

Tests Become Flaky

Tests become flaky as they depend on the connection itself. If a database or a restful service is down, the tests dependent on them fail.

Tests that sometimes work and sometimes do not, break the trust of a team. Sometimes just because of that people stop paying attention to the test suite and may not fix them. After some time such tests become unmaintainable and people stop using them. As a result, the entire investment in creating such tests goes in a drain.

[Read more…] about Introducing Mocktail: A Java Framework to Cache/Mock the External Dependency Response for Automated Tests

Specification by Example | Behavior Driven Development | ATDD – A Google Hangout Interview

by Leave a Comment

Recently I got interviewed by DiscussAgile on a topic known by several names, i.e. Specification by Example, Behavior Driven Development or Acceptance Test Driven Development.

Here’s the Google Hangout recording available on YouTube.

Following topics got discussed as part of interview:

  1. Why to do ATTD?
  2. How to do it?
  3. What skills are needed to do it?
  4. Who should do it?
  5. How it relates with Test Driven Development?
  6. Tools to BDD/ATDD.
  7. How to start?

Enjoy and provide your feedback.

When BDD (Behaviour Driven Development) may not work?

by 6 Comments

For quite some time there have been talks on using BDD in order to have:
  1. Better collaboration between Business Analysts (BAs), developers and testers.
  2. A common domain language for functional testing and for defining functional acceptance criteria, which everybody in the team understands.

Why BDD?

BDD offers following advantages:

  • Ability to write test cases (scenarios) and acceptance criteria before performing any development. This whole idea is termed as Acceptance Test Driven Development (ATDD).
  • Provides a common domain language, which everybody across the board (developer, tester, BA and business) understands. As at the end it’s plain English, it’s simplest to learn compared to other DSLs (domain specific languages).BDD example
    bdd-sample
  • Helps in eliminating waste by minimizing handshakes. If you take a look at the above-mentioned example, testers and BAs can write a test or acceptance scenario using a BDD template (highlighted in Yellow) with plane English

Developer/tester can then fill in the blanks, i.e. implement the test case using programming language or script.

Writing text doesn’t require any IDE like Visual Studio or Eclipse. The test/acceptance scenario can be written in a Notepad too and then pushed to Version Control System, which is then picked up by developers/testers to implement.

As BAs, developers and testers work only one single source of truth (BDD test), it minimizes the handshakes and reduces waste. Also it is well understood by everyone as test-scenario is in plain English.

[Read more…] about When BDD (Behaviour Driven Development) may not work?