DEV Community

Fauzan
Fauzan

Posted on • Edited on

Test Driven Development and Behaviour Driven Development in NodeJS

TDD atau Test Driven Development atau Test-First Development adalah proses pengembangan software yang bergantung pada persyaratan software yang dikonversikan ke bentuk test cases (unit testing maupun integration testing) terlebih dahulu sebelum softwarenya dikembangkan secara penuh Test First, Developed Later. Ini adalah lawan dari Test-Last Development Developed First, Test Later.

Unit Test

Unit Test adalah salah satu tipe dari software testing dimana setiap bagian atau komponen pada software akan di-test. Alasannya supaya hasil dari setiap bagian atau komponen akan sesuai yang diharapkan atau sesuai behaviournya (BDD).

Unit Test adalah bentuk dari White Box Testing, dimana yang di-test adalah struktur internal aplikasi sebuah software, contohnya utility ataupun bagian kecil pendukung jalannya fungsi-fungsi pada internal aplikasi.

Integration Test

Integration Test adalah salah satu tipe dari software testing dimana setiap fitur yang ada pada internal aplikasi itu sendiri akan di-test, misalnya dalam bentuk Rest API. Berbeda dari Unit Test yang melakukan test pada bagian kecil pada REST API, dimana kode kode utility pada Rest API, seperti untuk mengecek tipe data ataupun konversi format data.

Integration Test adalah bentuk dari Black Box Testing, dimana yang di-test adalah internal aplikasi sebuah software, contohnya fungsionalitas yang mendukung jalannya aplikasi.

BDD

BDD atau Behaviour Driven Development adalah bentuk pendekatan pada TDD, dimana setiap test menciptakan behaviour dari sistem untuk arahan pengembangan selanjutnya.

Misalnya dengan menspesifikasikan Given-When-Then formula, dimana analoginya Given adalah fitur yang akan dibuat, When adalah kapan fiturnya dijalankan, dan Then adalah apa yang terjadi setelah fiturnya dijalankan. Formula ini akan diterapkan di unit test yang tidak memiliki fitur terkait, dengan tujuan menulis test behaviour dari fitur tersebut terlebih dahulu sebelum membuat fiturnya, dan terus melakukan refactor. Failing Test First, Developed, Refactor If Necessary, Pass Test Last.

Pada saat mengembangkan fitur setelah membuat test cases, maka kita bisa menyebutnya sebagai TDD, namun hanya saja kita melakukan pendekatan BDD, dimana kita menulis behaviour dari sistemnya menjadi test cases terlebih dahulu. Ini sama saja seperti kita menyiapkan skenario terlebih dahulu sebelum membuat sebuah film yang sudah siap diceritakan kepada orang lain.

Bermain dengan Mocha dan Chai pada NodeJS

Sebelum memulai

Sebelum melanjutkan, silahkan install NodeJS terlebih dahulu. Versi Active LTS sangat disarankan.

Jika anda sudah menginstall NodeJS, mari belajar menggunakan npm init terlebih dahulu sebelum menginstall mocha didalam scope project setelah perintah npm init tersebut dijalankan.

# cek apakah npm sudah terinstall
npm -v

# mari berasumsi bahwa kita belum meng-init project dengan npm
npm init -y # atau npm init untuk menulis value pada package.json secara manual menggunakan CLI

# install sebagai devDependencies untuk menjalankan bin dari npm 
# package secara langsung pada `scripts` tanpa global installation
npm install -D mocha

# kita akan menggunakan chai sebagai assertion library,
# dimana assertion library ini yang akan menentukan
# apakah hasil dari sebuah fitur atau bagian pada software
# sesuai ekspektasi kita atau tidak.
npm install chai
Enter fullscreen mode Exit fullscreen mode

Memulai

Disini kita akan membuat sebuah contoh unit test dimana kita menciptakan skenario terlebih dahulu sebelum membuat fitur, disini sebagai contoh sederhana kita akan menerapkan FIFO algorithm pada Javascript namun menggunakan skenario supplier yang mengeluarkan dan memasukkan barang.

Dibawah ini hanyalah contoh test cases sederhana saja, anda bisa belajar membuat dan refactor test cases secara mandiri dengan contoh dibawah jika anda ingin mendalami lebih.

supplier.test.js
Pertama, adalah membuat skenario untuk supplier.

const chai = require("chai");

const expect = chai.expect;

describe("supplier", function () {
  const goods = [];

  it("supplier supplying goods", function () {
    // goods should increased
    expect(goods).to.have.lengthOf.at.least(1);
  });

  it("supplier demanding goods", function () {
    // goods should decreased
    expect(goods).to.have.lengthOf.at.least(0);
  });
});
Enter fullscreen mode Exit fullscreen mode

Setelah itu, file package.json anda kurang lebih harus ditambahkan scripts baru seperti dibawah ini.

"scripts": {
  "test": "mocha supplier.test.js"
},
Enter fullscreen mode Exit fullscreen mode

queue.js
Lalu, mari kita membuat bagian pendukung pada skenario supplier.

class Queue {
  constructor(...elements) {
    // set array as value of construct args
    this.elements = [...elements];
  }

  push(...args) {
    // push arguments to this.elements
    return this.elements.push(...args);
  }

  shift() {
    // you can also use splice
    //return this.elements.splice(0,1)[0];
    return this.elements.shift();
  }

  // access method as property (modern JS Engine)
  get length(){
    return this.elements.length;
  }

  // set method in property (modern JS Engine)
  set length(length){
    return this.elements.length = length;
  }
}
Enter fullscreen mode Exit fullscreen mode

Terakhir, mari kita modifikasi skenario yang sebelumnya ada pada test cases.

const chai = require("chai");

const Queue = require("./queue.js");

const expect = chai.expect;

describe("supplier", function () {
  const goods = new Queue();

  it("supplier supplying goods", function () {
    goods.push(1);
    expect(goods).to.have.lengthOf.at.least(1);
  });

  it("supplier demanding goods", function () {
    while(goods.length)
        console.log(goods.shift());
    expect(goods).to.have.lengthOf.at.least(0);
  });
});
Enter fullscreen mode Exit fullscreen mode

Untuk menjalankan test.

npm run test
Enter fullscreen mode Exit fullscreen mode

Selain menggunakan Mocha dan Chai, anda dapat menggunakan Jest ataupun Node TAP, pada dasarnya semua library testing pada Javascript tersebut sama-sama dibuat untuk software testing hanya saja secara benefit memiliki perbandingan yang dapat dipertimbangkan lebih lanjut.

Seperti itulah gambaran test cases dalam bentuk skenario (BDD) yang akan dibuat sebelum menciptakan suatu fitur.

Semoga bermanfaat untuk teman-teman pengembang software semuanya. 😄

Top comments (0)