Centro di sviluppo / Adattatore di prova

Test senza dispositivo

Utilizzare una falsa porta di cattura per verificare l'inventario e le regole di ricezione in CI prima che un palmare fisico è disponibile.

Standard di pubblicazioneSviluppatori

Collega e convalida la tua applicazione sull'hardware di destinazione.

Test di logica aziendale che non richiedono Android dispositivo, scanner o fornitore binario.

Squadre che vogliono test di unità veloci e un limite pulito tra regole del flusso di lavoro e chiamate hardware.

Le risorse pubbliche si concentrano su modelli di integrazione riproducibili. SDK, firmware e documenti soggetti a restrizioni restano nei canali di distribuzione autorizzati.

Dati comparabili sui dispositivi, con metodo, versione e limiti dichiarati.

Risorse per gli sviluppatoriAdattatore di prova
RuggedLayer Laboratorio di provaPrincipiante
Guide tecniche, note sull'SDK, app di esempio e dati di compatibilità per dispositivi Android robusti con codici a barre e RFID.Squadre che vogliono test di unità veloci e un limite pulito tra regole del flusso di lavoro e chiamate hardware.
  • Una funzione di dominio che consuma un evento di cattura normalizzato.
  • Un quadro di prova già in esecuzione nel progetto.
  • Una regola chiara per ciò che dovrebbe accadere con valori duplicati, vuoti e non validi.

Standard di pubblicazione

Crea e valida integrazioni Android aziendali con evidenze versionate.

Le risorse pubbliche si concentrano su modelli di integrazione riproducibili. SDK, firmware e documenti soggetti a restrizioni restano nei canali di distribuzione autorizzati.

  1. 01

    A seconda della porta, non della classe di dispositivo

    Il flusso di lavoro ricevente dovrebbe conoscere CaptureEvent e CapturePort. Non deve importare un manager dello scanner, trasmettere il tipo costante o modello-specifico.

  2. 02

    Emettere eventi deterministici

    Dai ai falsi metodi espliciti dell'adattatore una scansione valida, una scansione duplicata, un valore vuoto e un guasto.

  3. 03

    Risultati aziendali

    Controlla il movimento delle azioni, i messaggi di validazione e la gestione duplicata. Non asserisce che un callback del fornitore è stato chiamato da un test aziendale; che appartiene al test dell'adattatore hardware.

  4. 04

    Mantenere il test hardware piccolo

    Quando un dispositivo è disponibile, eseguire un test di fumo concentrato per l'apertura, il trigger, la decodifica e la chiusura.

App di esempio / Kotlin

Modelli SDK e API

È sicuro pubblicare perché non include una classe di fornitori o un binario.

fake-capture-port-test.kt

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)
}
Nessun codice binario del fornitore, riferimento API, firmware o esempio di origine viene pubblicato finché non vengono registrati l'autorizzazione di ridistribuzione e l'ambito supportato.

Distribuzione dell'SDK

Criteri di pubblicazione

Nessun codice binario del fornitore, riferimento API, firmware o esempio di origine viene pubblicato finché non vengono registrati l'autorizzazione di ridistribuzione e l'ambito supportato.

Test ha bisogno di un vero dispositivo per eseguire

Spostare la configurazione hardware in un piccolo test di fumo dell'adattatore e mantenere le regole di dominio sulla porta finta.

La stessa scansione è accettata due volte

Aggiungere un evento duplicato esplicito e affermare la transizione di stato una volta.

Un valore vuoto raggiunge il repository

Rifiutare al limite di normalizzazione e esporre uno stato recuperabile dall'utente.

Stati delle evidenze

Dati comparabili sui dispositivi, con metodo, versione e limiti dichiarati.

  1. 01

    Eseguire i test dell'adattatore falso su ogni CI costruire.

  2. 02

    Coprire casi validi, vuoti, duplicati, oversize e di trasporto.

  3. 03

    Tenere l'adattatore specifico del dispositivo dietro un limite del pacchetto.

  4. 04

    Eseguire un test di fumo fisico-dispositivo separatamente per ogni linea di base approvata.

Collega e convalida la tua applicazione sull'hardware di destinazione. Collegare lo scanner approvato SDK a CapturePort senza cambiare il flusso di lavoro ricevente.

Risorse

Modelli SDK e API

Nessun codice binario del fornitore, riferimento API, firmware o esempio di origine viene pubblicato finché non vengono registrati l'autorizzazione di ridistribuzione e l'ambito supportato.

Collega e convalida la tua applicazione sull'hardware di destinazione.

Condividi il flusso applicativo non riservato, il dispositivo attuale e il percorso di integrazione; definiremo il deliverable di validazione più adatto.

Collega e convalida la mia applicazione