Come dovrei affrontare il test del codice su un progetto solista?

3

Sto scrivendo un pezzo di software e vorrei pubblicarlo open source.

Dovrei provare a renderlo stabile sul mio computer (con uso normale, senza "cose che una scimmia non farebbe mai") prima di rilasciarlo, o dovrei adottare un approccio diverso?

Quello che mi sto proponendo di fare adesso è:

  1. Scrivilo io stesso durante la fase pre-alpha per renderlo parzialmente utilizzabile. Gioca con le funzioni (come farebbe una persona normale).
  2. Rilascia pubblicamente e aggiungi alcuni campanelli e fischi durante la fase alpha
  3. Dì che è in beta una volta che tutte le funzioni sono complete, quindi, insieme ad altre (si spera), esegui il "test delle scimmie".
  4. Genera la pubblicità per il mio progetto [abbastanza semplice e noioso, ma comunque abbastanza buono e stable ].

Quindi continua a migliorarlo. Questo sembra essere un sistema usuale (per me, quello che non ha mai fatto tutto questo mai prima d'ora).

C'è qualcosa che posso fare per verificare automaticamente gli errori di base prima di andare in alpha? O è questa una delle cose migliori che posso fare? Come dovrei andare sul test?

    
posta Anonymous Penguin 29.07.2013 - 22:39
fonte

3 risposte

3

Dato che sono un po 'nella tua situazione (attualmente sto sviluppando un CMS basato su PHP), spero che la mia esperienza possa aiutarti.

Il test è la chiave. Ripeti fino a quando non credi. Dipende dal linguaggio di programmazione anche se è facile. Come sto sviluppando in PHP, darò alcuni esempi su questo.

sviluppo

Il punto più importante è: tu sviluppi il software in primo luogo per te stesso. Se fai qualcosa nel tuo tempo libero, fallo da solo, fallo per divertimento. Non farlo nell'aspettativa di "Voglio che gli altri contribuiscano al progetto". Se metti una base di codice vuota, nessuno contribuirà. Per i primi contributori hai bisogno di una demo in esecuzione, qualcosa che rende popolare il tuo software.

Per raggiungere questo obiettivo è necessario sviluppare il software in primo luogo.

  • Crea un elenco di funzionalità.
  • Chiediti: cosa dovrebbe essere nel prodotto, cosa no?

Questa lista di funzionalità non è santa. Cambierà durante lo sviluppo e non sarai in grado di realizzare tutto come pianificato. Ma ti dà una direzione generale, alcuni obiettivi su cui puntare.

Test

Crea un software che è adatto ai test. Utilizzare l'iniezione di dipendenza, prevenire i singleton e utilizzare i test di unità. Nel migliore dei casi utilizzare lo sviluppo guidato da test. Ciò significa che crei prima il test e la classe testata. In questo modo devi conoscere le specifiche della tua classe prima di scriverlo. In seguito risparmia molto dolore e motiva i contributori (devono solo testare le proprie classi). I cambiamenti di implementazione possono essere semplicemente testati e se falliscono, puoi immediatamente risolvere gli errori.

Stampa

Annuncia il software solo se funziona e senza problemi. Ma usa Github o un altro sito di hosting di codice per dare ai primi contributori la possibilità di vedere il codice. Se vogliono, possono contribuire. Ma tu sei lo sviluppatore principale della prima versione.

Una volta che la prima versione si avvicina alla Beta (tutti i componenti sono principalmente scritti e testati e funzionano insieme), puoi creare una demo pubblica (mostrando il tuo prodotto in caso di software web). Raccogliere feedback degli utenti generali del software (cosa manca ?, cosa si può fare meglio?). Ciò garantisce che non manchi la base clienti. L'elenco delle caratteristiche iniziali sarà concentrato sull'attenzione degli sviluppatori di funzionalità. Questo è naturale e OK. Ma per questo hai bisogno di questo feedback Beta dei tuoi potenziali utenti.

Poi passa sopra il feedback, sviluppa funzionalità mancanti, correggi bug esistenti, ecc. Una volta che tutto funziona (test automatici come test unitari e test funzionali renderanno tutto molto più semplice) puoi rilasciare il tuo prodotto.

Manutenzione

Il tuo lavoro non è finito quando è fuori. Quando è iniziato, inizia il tuo vero lavoro. Ora devi promuovere il tuo prodotto (sia l'uso che lo sviluppo del codice) sul sito web del tuo prodotto. Scrivi una buona documentazione per gli sviluppatori (oltre alla documentazione dell'API generata dai commenti del codice) che spiega le cose che non troverai nella documentazione dell'API (best practice, cosa fare e cosa non fare, ecc.).

    
risposta data 30.07.2013 - 08:24
fonte
5

Il test delle unità è ciò di cui il tuo progetto ha bisogno per diversi motivi.

  1. Consente di testare le funzionalità di base dell'applicazione.
  2. Consente di garantire che le nuove funzionalità non causino regressioni.
  3. I buoni test unitari danno ai consumatori e ai manutentori un'idea di cosa è capace la tua applicazione.
  4. I buoni test unitari concisi ti incoraggiano a scrivere un buon codice conciso. Dopo tutto, un buon codice conciso è più facile da testare.
risposta data 30.07.2013 - 02:11
fonte
2

I test unitari faranno aumentare il tempo di sviluppo iniziale. Ma in compenso eviterai molti di quegli insidiosi bug emergenti man mano che il tuo sistema cresce. Inoltre, quando raggiungi un certo livello di complessità del progetto, i tuoi test unitari potrebbero iniziare a risparmiare tempo di sviluppo, poiché la maggior parte della codifica probabilmente coinvolgerà codice precedente e i test unitari ti forniranno una solida certezza per non rompere nulla che in precedenza funzionava. p>

Un altro punto a favore dei test delle unità di codifica è che tende a produrre un codice migliore in quanto, in generale, il codice testabile è meno accoppiato rispetto al codice difficile da testare.

Se si tratta di un'applicazione Web che stai sviluppando, i test automatici funzionali sono un ottimo modo per invertire il test dell'applicazione dopo aver apportato alcune modifiche. Ho usato Selenium per questo scopo prima.

    
risposta data 30.07.2013 - 00:51
fonte

Leggi altre domande sui tag