Belajar IoT Engineer - IoT Testing & Simulation

#Pendahuluan

Sejauh ini kita membangun banyak hal: firmware, protokol, cloud, pipeline. Sekarang pertanyaannya: bagaimana memastikan semuanya benar-benar bekerja? Di IoT, kesalahan tidak menampilkan error screen — perangkat di lapangan hanya diam, dan kalian tidak bisa "remote debug" 10.000 unit.

Mengapa testing IoT berbeda? Karena sistem IoT punya tiga lapisan yang harus diuji: firmware (yang berjalan di hardware), komunikasi (protokol & jaringan), dan cloud/backend. Kegagalan bisa terjadi di lapisan mana pun — dan mendiagnosisnya lintas lapisan jauh lebih sulit daripada debugging aplikasi web.

#Test Pyramid untuk Firmware

Pola klasik test pyramid berlaku juga untuk IoT:

        /\
       /  \      Uji end-to-end (sedikit)
      /____\     
     /      \    Uji integrasi (sedang)
    /________\   
   /          \  Unit test + hardware-in-loop (banyak)
  /____________\

Semakin ke bawah, semakin banyak dan cepat. Aturan: sebagian besar bug dicegat di unit test, karena paling murah diperbaiki.

#Unit Test untuk Firmware

Firmware bisa di-unit-test dengan memisahkan logika dari hardware. Contoh: fungsi yang memutuskan apakah alarm harus aktif (logika murni, tanpa I/O):

#ifndef ALARM_H
#define ALARM_H
 
bool shouldRaiseAlarm(float temperature, bool alarmActive) {
    // hysteresis: nyala di >45C, mati di <40C
    if (temperature > 45.0f) return true;
    if (temperature < 40.0f) return false;
    return alarmActive;
}
 
#endif

#include <unity.h>
#include "alarm.h"
 
void test_alarm_turns_on_above_threshold() {
    TEST_ASSERT_TRUE(shouldRaiseAlarm(45.5f, false));
}
 
void test_alarm_stays_active_in_hysteresis() {
    TEST_ASSERT_TRUE(shouldRaiseAlarm(42.0f, true));
}
 
void test_alarm_turns_off_below_low_threshold() {
    TEST_ASSERT_FALSE(shouldRaiseAlarm(39.0f, true));
}
 
void setup() {
    UNITY_BEGIN();
    RUN_TEST(test_alarm_turns_on_above_threshold);
    RUN_TEST(test_alarm_stays_active_in_hysteresis);
    RUN_TEST(test_alarm_turns_off_below_low_threshold);
    UNITY_END();
}
 
void loop() {}

Dengan Unity (framework test C), logika diuji di PC maupun ESP32 — tanpa harus memegang hardware untuk setiap perubahan. Pola ini disebut hardware abstraction: isolasi logika yang bisa diuji dari driver yang tidak.

#Simulasi dan Emulasi Perangkat

Tidak semua orang punya hardware fisik selalu tersedia. Dua cara menguji tanpa hardware:

#Simulasi Cloud dengan Virtual Device

Untuk menguji pipeline cloud (episode 8) tanpa firmware, buat virtual device — script yang berperan sebagai ratusan perangkat:

import random
import time
import paho.mqtt.client as mqtt
 
BROKER = "localhost"
DEVICES = [f"sim-{i:02d}" for i in range(10)]
 
client = mqtt.Client()
client.connect(BROKER, 1883)
 
while True:
    for dev in DEVICES:
        temp = 25 + random.uniform(-2, 5)
        client.publish(f"sensor/{dev}/telemetry",
                       f'{{"temperature":{temp:.1f}}}')
    time.sleep(5)

Jalankan di terminal:

python3 virtual-device.py &
mosquitto_sub -t "sensor/#" -v | head -5

sensor/sim-00/telemetry {"temperature":27.3}
sensor/sim-01/telemetry {"temperature":25.9}
sensor/sim-02/telemetry {"temperature":28.6}

Teknik ini penting untuk menguji cloud sebelum perangkat nyata siap — dan untuk load test (episode 21) dengan ribuan virtual device.

#Emulator Wokwi untuk Menguji Firmware

Wokwi menyimulasikan ESP32 di browser: kalian bisa merangkai sensor virtual, menulis firmware, dan menjalankannya — bahkan menguji koneksi WiFi. Ideal untuk: verifikasi logika cepat, mengajar, dan CI tanpa hardware.

#Hardware-in-the-Loop (HIL)

Setelah unit test dan simulasi lulus, uji dengan hardware nyata di lingkungan terkontrol (HIL): firmware + sensor sungguhan + broker lokal. Ini menangkap masalah yang tidak muncul di simulasi — timing, noise listrik, driver bug.

1. Unit test logika (PC/Unity)
2. Simulasi virtual device (cloud tanpa hardware)
3. Emulator Wokwi (firmware tanpa hardware)
4. HIL: firmware + hardware nyata + broker lokal
5. E2E: device nyata → cloud → dashboard

#Menguji Komunikasi dan Reliability

Selain fungsionalitas, uji hal-hal yang khas IoT:

• Reconnect — matikan broker, hidupkan lagi; perangkat harus reconnect dan tidak macet.
• Power cycle — cabut listrik perangkat saat mengirim data; pastikan tidak ada state korup.
• Long run (soak test) — jalankan perangkat 24–72 jam; pantau memory leak dan drift.
• Packet loss — pindahkan perangkat ke lokasi sinyal lemah; lihat bagaimana buffering bekerja.
• Clock/time drift — perangkat tanpa RTC bisa meleset; pastikan NTP sync.

#Kesalahan Umum

1. Hanya menguji "happy path" — uji juga reconnect, power loss, dan sinyal lemah.
2. Mengandalkan serial print untuk debugging produksi — tidak ada terminal di lapangan; log harus dikirim ke cloud.
3. Testing hardware selalu manual — investasi di unit test dan HIL; uji manual tidak terulang.
4. Simulasi terlalu sempurna — Wokwi tidak menangkap noise listrik; tetap butuh uji hardware nyata.
5. Tidak menguji soak test — memory leak baru muncul setelah berhari-hari berjalan.

#Penutup

Inti yang harus dibawa pulang:

• Test pyramid IoT: unit test banyak, HIL sedang, E2E sedikit.
• Pisahkan logika dari hardware agar bisa di-unit-test (Unity).
• Virtual device menguji cloud tanpa hardware; Wokwi menguji firmware tanpa hardware.
• HIL (hardware nyata) wajib sebelum rilis — simulasi tidak menangkap noise nyata.
• Uji skenario khas IoT: reconnect, power cycle, soak test, packet loss, time drift.

Di episode 17 selanjutnya, kita akan mengotomasi semua pengujian ini: firmware CI/CD & DevOps — membangun pipeline otomatis untuk build, test, dan release firmware, plus praktik menyiapkan GitHub Actions untuk proyek PlatformIO. Dari "bisa" menjadi "bisa berulang-ulang dan aman"!