Flusso di lavoro basato su REPL e test unitario

Question

Flusso di lavoro basato su REPL e test unitario

#1 da (4 voti)

3

Come sviluppatore che ha lavorato principalmente alla programmazione funzionale in F # negli ultimi anni, sono molto affezionato al mio REPL e lo uso eseguendo il mio codice mentre procedo, testando e perfezionando ogni funzione mentre scrivo. Tuttavia, un'area in cui spesso non riesco come sviluppatore sta creando buoni test unitari per ogni funzione e li invio con la mia richiesta iniziale di revisione del codice.

Altri sviluppatori del mio team che provengono da uno sfondo più OOP / C # hanno un flusso di lavoro che è inferiore a REPL-driven e usa i test unitari (MSTEST) per eseguire i test sperimentali che faccio nel REPL. Mentre questo li lascia con un gruppo di unit test alla fine del loro ciclo, preferisco ancora il REPL, perché posso scorrere e testare molto più velocemente, senza dover costruire il progetto e attendere il motore di test ogni volta.

Dato che siamo un team di F #, ritengo che REPL sia lo strumento giusto per i test sperimentali durante lo sviluppo, ma ritengo anche che occorrano test unitari di unità che vengano eseguiti durante i build come parte del nostro processo di check-in. Inoltre non mi piace particolarmente, dato che dobbiamo creare classi di test e metodi di test per i test unitari, dal momento che in realtà non usiamo le classi molto spesso altrove, ma posso occuparmene. Il valore di avere una serie ripetibile di test eseguiti su ogni build per evidenziare immediatamente eventuali modifiche di rottura è abbastanza utile per gestire le idiosincrasie di un framework di test OOP.

Nel fare alcune ricerche, ho visto cose come l' Cursive IDE per Clojure che combina un REPL con il clojure.test framework in modo che il codice che scrivi nel REPL possa diventare il test unitario. Sembra una soluzione ideale e sembra che il progetto di test F # Expecto possa parzialmente supportare questo modello, quindi sto pensando di fare una proposta per provarlo. Tuttavia, non voglio introdurre modifiche dirompenti al flusso di lavoro e al processo di test a meno che non sia la migliore soluzione disponibile.

Sono state apportate alcune semplici modifiche al flusso di lavoro che ho trascurato per risolvere il problema senza modificare gli strumenti di test? In che modo REPL e Unit Test vengono utilizzati insieme in altri grandi progetti basati su FP?

unit-testing functional-programming f#

posta InitialValue 10.10.2018 - 16:33

fonte

1 risposta

Leggi altre domande sui tag unit-testing functional-programming f#

php | architect è buono? Problema di licenza del nome dell'applicazione

score 4 · Answer 1

Lo sviluppo di

Read-Eval-Print Loop (REPL) dovrebbe preoccuparsi delle funzioni "crescenti" utilizzabili. I test unitari dovrebbero riguardare il test di quelle funzioni per assicurarsi che funzionino correttamente. Non c'è nulla di fondamentalmente in disaccordo con queste due idee, oltre al lavoro aggiuntivo richiesto per scrivere i test unitari, che probabilmente è qualcosa che dovresti fare comunque.

Ci sono sempre stati due modi per scrivere i test unitari: prima o dopo aver scritto il codice sotto test. Test-Driven Development , che è tradizionalmente Test First, probabilmente eliminerà tutti i vantaggi che il REPL ti offre, perché ora scriverete i test unitari per ciascuno dei vostri passaggi REPL intermedi, il che vi rallenterà.

Quindi ecco cosa consiglierei. Scrivi test di unità dopo aver scritto le tue funzioni. Scopri cosa dovrebbe fare la tua funzione (cioè crea una specifica per ogni funzione), scrivi la funzione usando le tue tecniche REPL, e poi avvolgerlo in test unitari secondo le vostre specifiche. In altre parole, i test unitari dovrebbero dimostrare che la funzione soddisfa le sue specifiche, i suoi requisiti dichiarati.

Questo ti offre i vantaggi dei test unitari senza intralciare il rapido sviluppo fornito da REPL, con modifiche minime al flusso di lavoro corrente.

Naturalmente, nulla ti impedisce di usare Expecto nello stesso modo, usando lo stesso flusso di lavoro che ho appena descritto. Expecto sembra avere una serie di vantaggi che MSTest non offre, come test delle prestazioni, capacità di stress testing, capacità di supportare più core e test che non richiedono classi.

open Expecto

let tests =
  test "A simple test" {
    let subject = "Hello World"
    Expect.equal subject "Hello World" "The strings should equal"
  }