Come faccio a testare in modo efficace un motore di scripting?
-
23-10-2019 - |
Domanda
Ho lavorato su un'implementazione ECMAScript e attualmente sto lavorando sulla lucidatura il progetto. Come parte di questo, ho scritto i test come il seguente:
[TestMethod]
public void ArrayReduceTest()
{
var engine = new Engine();
var request = new ExecScriptRequest(@"
var a = [1, 2, 3, 4, 5];
a.reduce(function(p, c, i, o) {
return p + c;
});
");
var response = (ExecScriptResponse)engine.PostWithReply(request);
Assert.AreEqual((double)response.Data, 15D);
}
Il problema è che ci sono tanti punti di guasto in questo test e prove simili che quasi non sembra vale la pena. Sembra quasi che il mio sforzo sarebbe stato speso meglio ridurre l'accoppiamento tra i moduli. Per scrivere un vero e proprio test di unità che avrei dovuto assumere qualcosa di simile:
[TestMethod]
public void CommentTest()
{
const string toParse = "/*First Line\r\nSecond Line*/";
var analyzer = new LexicalAnalyzer(toParse);
{
Assert.IsInstanceOfType(analyzer.Next(), typeof(MultiLineComment));
Assert.AreEqual(analyzer.Current.Value, "First Line\r\nSecond Line");
}
}
In questo modo mi avrebbe richiesto di scrivere migliaia di test che ancora una volta non sembra vale la pena.
Soluzione
Proprio spitballing qui, ma cosa succede se si è memorizzato i test in un file / database / etc ... (come Doug punti su - la capacità di conservare in controllo di versione rende i file la scelta migliore) Ogni voce potrebbe avere un nome , uno script, e l'output previsto.
Poi si può solo scrivere una piccola applicazione che esegue ogni script utilizzando il motore e lo confronta con l'uscita per i risultati attesi, e avvisa di successo / insuccesso in base al risultato.
Ciò non si salva dalla necessità di testare i punti di dolore nel motore di script in sé, ma potrebbe essere più facile da mantenere qualcosa di simile che a dare una prova di unità per ogni modo che è possibile immaginare utilizzando il runtime di scripting.