Publiczne zasoby koncentrują się na powtarzalnych wzorcach integracji. SDK, firmware i dokumenty objęte ograniczeniami pozostają w zatwierdzonych kanałach dystrybucji.
Porównywalne dane o urządzeniach z opisaną metodą, wersją i ograniczeniami.
- Funkcja domeny, która wykorzystuje znormalizowane zdarzenie przechwytywania.
- Struktura testowa już działająca w projekcie.
- Jasna zasada określająca, co powinno się dziać w przypadku zduplikowanych, pustych i nieprawidłowych wartości.
Norma wydawnicza
Twórz i weryfikuj integracje firmowych aplikacji z urządzeniami Android na podstawie wersjonowanych danych.
Publiczne zasoby koncentrują się na powtarzalnych wzorcach integracji. SDK, firmware i dokumenty objęte ograniczeniami pozostają w zatwierdzonych kanałach dystrybucji.
- 01
Zależy od portu, a nie klasy urządzenia
Przepływ pracy odbierający powinien znać CaptureEvent i CapturePort. Nie powinien importować menedżera skanera, stałej rozgłoszeniowej ani typu specyficznego dla modelu.
- 02
Emituj zdarzenia deterministyczne
Podaj fałszywemu adapterowi jawne metody prawidłowego skanowania, skanowania zduplikowanego, pustej wartości i niepowodzenia. Testy stają się czytelne, gdy dane wejściowe opisują scenariusz operatora.
- 03
Potwierdź wyniki biznesowe
Sprawdź przepływ zapasów, komunikaty weryfikacyjne i obsługę duplikatów. Nie należy twierdzić, że wywołanie zwrotne dostawcy zostało wywołane w wyniku testu biznesowego; który należy do testu adaptera sprzętowego.
- 04
Staraj się, aby test sprzętu był niewielki
Gdy urządzenie jest dostępne, przeprowadź skoncentrowany test dymu w celu otwarcia, wyzwalania, dekodowania i zamykania. Większy pakiet przepływu pracy powinien pozostać szybki i wolny od urządzeń.
Przykładowe aplikacje / Kotlin
Wzorce SDK i API
Oryginalny podwójny test. Publikowanie jest bezpieczne, ponieważ nie zawiera klasy dostawcy ani pliku binarnego.
class FakeCapturePort : CapturePort {
private var listener: ((CaptureEvent) -> Unit)? = null
override fun open() = Unit
override fun start() = Unit
override fun stop() = Unit
override fun close() = Unit
override fun setListener(listener: (CaptureEvent) -> Unit) {
this.listener = listener
}
fun emit(value: String, symbology: String? = "test") {
listener?.invoke(CaptureEvent(value, symbology, Instant.now()))
}
}
@Test
fun receiving_a_valid_barcode_updates_stock() {
val scanner = FakeCapturePort()
val workflow = ReceivingWorkflow(scanner)
workflow.start()
scanner.emit("SKU-001")
assertEquals(ReceivingState.Accepted("SKU-001"), workflow.state)
}Dystrybucja SDK
Warunki publikacji
Żadne pliki binarne dostawcy, odniesienia do API, oprogramowanie sprzętowe ani próbki źródłowe nie są publikowane, dopóki nie zostaną zarejestrowane uprawnienia do redystrybucji i obsługiwany zakres.
Przenieś konfigurację sprzętu do małego testu dymnego adaptera i zachowaj reguły domeny na fałszywym porcie.
Dodaj jawnie zduplikowane zdarzenie i jednokrotnie potwierdź zmianę stanu.
Odrzuć na granicy normalizacji i udostępnij stan możliwy do odzyskania przez użytkownika.
Status dowodów
Porównywalne dane o urządzeniach z opisaną metodą, wersją i ograniczeniami.
- 01
Uruchom fałszywe testy adaptera w każdej kompilacji CI.
- 02
Obejmuje przypadki ważne, puste, duplikaty, ponadgabarytowe i związane z awariami transportowymi.
- 03
Trzymaj adapter specyficzny dla urządzenia za granicą jednego pakietu.
- 04
Przeprowadź oddzielnie jeden test dymu na urządzeniu fizycznym dla każdej zatwierdzonej linii bazowej.
Zasoby
Wzorce SDK i API
Żadne pliki binarne dostawcy, odniesienia do API, oprogramowanie sprzętowe ani próbki źródłowe nie są publikowane, dopóki nie zostaną zarejestrowane uprawnienia do redystrybucji i obsługiwany zakres.