Pengertian pengujian

Saat menulis software, Anda dapat memastikan bahwa software tersebut berfungsi dengan benar melalui pengujian. Pengujian dapat didefinisikan secara luas sebagai proses menjalankan perangkat lunak dengan cara untuk memastikan bahwa kode berperilaku sebagaimana mestinya.

Pengujian yang berhasil dapat memberi Anda keyakinan bahwa saat Anda menambahkan kode, fitur, atau bahkan meningkatkan dependensi Anda, perangkat lunak yang telah Anda tulis akan terus bekerja seperti yang Anda harapkan. Pengujian juga dapat membantu mengamankan terhadap skenario yang tidak mungkin atau input yang tidak diharapkan.

Beberapa contoh perilaku di web yang mungkin ingin Anda uji meliputi:

  • Memastikan bahwa fitur situs beroperasi dengan benar saat tombol diklik.
  • Mengonfirmasi bahwa fungsi kompleks memberikan hasil yang benar.
  • Menyelesaikan tindakan yang memerlukan login pengguna.
  • Memastikan bahwa formulir melaporkan error dengan benar saat data yang salah dimasukkan.
  • Memastikan aplikasi web yang kompleks terus berfungsi ketika pengguna memiliki bandwidth rendah atau offline.

Pengujian otomatis versus manual

Anda dapat menguji software dengan dua cara umum: pengujian otomatis dan manual pengujian.

Pengujian manual melibatkan manusia yang menjalankan software secara langsung, seperti memuat situs Anda di browser mereka, dan mengonfirmasi bahwa perilakunya seperti yang diharapkan. Manual pengujian mudah dibuat atau ditentukan—misalnya, apakah situs Anda dapat dimuat? Dapatkah Anda melakukan tindakan ini?—tetapi setiap run-through memerlukan biaya yang waktu manusia. Meskipun manusia sangat kreatif, yang dapat memungkinkan jenis pengujian yang dikenal sebagai uji eksplorasi, kita masih bisa gagal dalam mendeteksi kegagalan atau inkonsistensi, terutama ketika melakukan tugas yang sama berkali-kali.

Pengujian otomatis adalah proses apa pun yang memungkinkan pengujian dikodifikasi dan dijalankan berulang kali oleh komputer untuk mengonfirmasi perilaku software yang Anda maksud tanpa meminta manusia untuk melakukan langkah berulang, seperti menyiapkan atau memeriksa hasil. Yang penting, setelah pengujian otomatis dikonfigurasi, pengujian otomatis dapat sering dijalankan. Definisi ini masih merupakan definisi yang sangat luas, dan perlu dicatat bahwa sistem tes mengambil segala macam bentuk dan bentuk. Sebagian besar materi ini membahas dirinya sendiri dengan pengujian otomatis.

Pengujian manual memang berperan, sering kali sebagai cikal bakal penulisan otomatis tetapi juga ketika pengujian otomatis menjadi terlalu tidak dapat diandalkan, cakupannya luas, atau sulit untuk ditulis.

Dasar-dasar melalui contoh

Bagi kami, sebagai developer web yang menulis JavaScript atau bahasa terkait, pengujian otomatis dapat berupa skrip seperti ini yang Anda jalankan setiap hari, mungkin melalui Node, atau dengan memuatnya di browser:

import { fibonacci } from "../src/math.js";

if (fibonacci(0) !== 0) {
  throw new Error("Invalid 0th fibonacci result");
}
const fib13 = fibonacci(13);
if (fib13 !== 233) {
  throw new Error("Invalid 13th fibonacci result, was=${fib13} wanted=233");
}

Ini adalah contoh sederhana yang memberikan insight berikut:

  • Ini adalah pengujian karena menjalankan beberapa software (Fibonacci ) dan memastikannya perilaku ini bekerja sesuai harapan, yaitu dengan memeriksa hasilnya terhadap nilai yang diharapkan. Jika perilakunya tidak benar, akan menyebabkan {i>error<i}, yang JavaScript mengekspresikan dengan menampilkan Error.

  • Meskipun Anda mungkin menjalankan skrip ini secara manual di terminal Anda atau browser, ini masih merupakan pengujian otomatis karena dapat dijalankan berulang kali tanpa harus melakukan langkah-langkah individual. Halaman berikutnya, di mana pengujian berjalan, untuk menjelaskan lebih lanjut.

  • Meskipun pengujian ini tidak menggunakan library apa pun—inilah JavaScript yang dapat dijalankan di mana saja—hal ini masih merupakan tes. Ada banyak alat yang dapat membantu Anda menulis tes, termasuk yang akan dibahas nanti dalam materi ini, tetapi semuanya masih bekerja berdasarkan prinsip dasar yang menyebabkan kesalahan jika terjadi masalah.

Menguji library dalam praktik

Sebagian besar library atau framework pengujian bawaan menyediakan dua primitif utama yang membuat pengujian lebih mudah ditulis: pernyataan dan cara untuk menentukan pengujian independen. Hal ini akan dibahas secara mendetail sebagai bagian dari bagian berikutnya, yaitu pernyataan dan sistem primitif lainnya. Namun, pada dasarnya, penting untuk diingat bahwa hampir semua pengujian yang Anda lihat atau tulis akan menggunakan primitif semacam ini.

Pernyataan adalah cara menggabungkan pemeriksaan hasil dan menyebabkan kesalahan jika terjadi masalah. Misalnya, Anda dapat membuat pengujian sebelumnya lebih ringkas dengan memperkenalkan assert:

import { fibonacci } from "../src/math.js";
import { assert } from "a-made-up-testing-library";

assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");

Anda dapat meningkatkan pengujian ini lebih lanjut dengan menentukan pengujian independen, atau yang dikelompokkan ke dalam suite. Suite berikut menguji Fibonacci secara independen dan fungsi Katala:

import { fibonacci, catalan } from "../src/math.js";
import { assert, test, suite } from "a-made-up-testing-library";

suite("math tests", () => {
  test("fibonacci function", () => {
    assert.equal(fibonacci(0), 0, "Invalid 0th fibonacci result");
    assert.equal(fibonacci(13), 233, "Invalid 13th fibonacci result");
  });
  test("relationship between sequences", () => {
    const numberToCheck = 4;
    const fib = fibonacci(numberToCheck);
    const cat = catalan(numberToCheck);
    assert.isAbove(fib, cat);
  });
});

Dalam konteks pengujian software, test sebagai kata benda mengacu pada kasus pengujian: a skenario tunggal, independen, dan dapat dialamatkan, seperti "hubungan antara urutan" dalam contoh sebelumnya.

Pengujian yang dinamai secara individual berguna untuk tugas berikut:

  • Menentukan bagaimana pengujian berhasil atau gagal dari waktu ke waktu.
  • Menyoroti {i>bug<i} atau skenario dengan namanya sehingga Anda dapat menguji dengan lebih mudah telah diselesaikan.
  • Menjalankan beberapa pengujian secara terpisah dari pengujian lainnya, seperti melalui filter glob.

Salah satu cara untuk memikirkan {i>test case<i} adalah menggunakan “tiga A” pengujian unit: mengatur, bertindak, dan menegaskan. Pada intinya, setiap kasus pengujian akan:

  • Atur beberapa nilai atau status (bisa berupa data input hard code).
  • Melakukan tindakan, seperti memanggil metode.
  • Nyatakan nilai output atau status yang diperbarui (menggunakan assert).

Skala pengujian

Contoh kode di bagian sebelumnya menjelaskan pengujian unit, karena pengujian tersebut menguji bagian kecil dari perangkat lunak Anda, sering kali berfokus pada satu file, dan dalam yang sama, hanya {i>output<i} dari satu fungsi. Kompleksitas pengujian terus berkembang seiring Anda pertimbangkan kode dari beberapa file, komponen, atau bahkan berbagai komponen yang saling berhubungan sistem organisasi (terkadang di luar kendali Anda, seperti layanan jaringan atau perilaku dependensi eksternal). Karena itu, jenis pengujian sering diberi nama berdasarkan cakupan atau skala.

Bersama dengan pengujian unit, beberapa contoh jenis pengujian lainnya mencakup komponen pengujian, pengujian visual, dan pengujian integrasi. Tak satu pun dari nama-nama ini memiliki definisi yang ketat, dan mungkin memiliki arti yang berbeda tergantung pada jadi ingatlah untuk menggunakannya sebagai panduan dan berikan definisi bekerja untuk Anda. Misalnya, apa yang dimaksud dengan komponen yang diuji dalam sistem Anda? Sebagai Developer React, ini mungkin secara harfiah dipetakan ke "Komponen React", tetapi mungkin memiliki arti yang berbeda bagi developer dalam konteks lain.

Skala pengujian individu dapat menempatkannya di dalam konsep yang sering disebut sebagai "piramida pengujian", yang bisa menjadi aturan praktis tentang pengujian pemeriksaan dan cara menjalankannya.

Piramida pengujian,
    dengan pengujian end-to-end (E2E) di bagian atas, pengujian integrasi di tengah, dan
    pengujian unit di bagian bawah.
Piramid pengujian.

Ide ini telah diiterasi, dan berbagai bentuk lainnya kini telah dipopulerkan, seperti berlian pengujian atau menguji kerucut es. Prioritas Anda dalam menulis pengujian mungkin akan unik bagi saat ini. Namun, fitur umumnya adalah pengujian yang lebih sederhana, seperti pengujian unit, cenderung lebih cepat dijalankan, lebih mudah untuk ditulis (sehingga Anda akan memiliki lebih banyak), dan menguji cakupan terbatas, sedangkan pengujian yang kompleks seperti pengujian menyeluruh sulit untuk ditulis tetapi dapat menguji ruang lingkup yang lebih luas. Bahkan, lapisan teratas dari banyak menguji 'bentuk' cenderung melalui pengujian manual, karena beberapa interaksi pengguna terlalu rumit untuk dikodifikasi ke dalam pengujian otomatis.

Jenis ini akan diperluas di jenis sistem pengujian.

Menguji pemahaman Anda

Primitif apa yang disediakan oleh sebagian besar library dan framework pengujian?

Layanan runner yang menggunakan penyedia cloud.
Beberapa pelari berbasis browser menawarkan cara untuk melakukan outsourcing pada pengujian, tetapi itu bukan fitur normal dari library pengujian.
Pernyataan yang menyebabkan pengecualian jika tidak puas.
Meskipun Anda dapat menampilkan error untuk menggagalkan pengujian, assert() dan variasinya cenderung dimasukkan karena membuat pemeriksaan lebih mudah untuk menulis.
Cara untuk mengategorikan pengujian ke dalam piramida pengujian.
Tidak ada cara standar untuk melakukan ini. Anda dapat memberi awalan pada nama pengujian Anda, atau menempatkannya dalam file yang berbeda, namun kategorisasi tidak benar-benar disertakan ke dalam sebagian besar kerangka kerja pengujian.
Kemampuan untuk menentukan pengujian independen berdasarkan fungsi.
Metode test() disertakan dalam hampir semua pengujian pelari. Penting karena kode pengujian tidak berjalan di tingkat teratas file, yang memungkinkan runner pengujian memperlakukan setiap kasus pengujian sebagai unit independen.