Come impedire all'implementazione / all'algoritmo di passare ai test unitari?

Un modo per evitare questa duplicazione è creare un dispositivo con valori esplicitamente definiti. In questo esempio devi configurare il canvas con valori esplicitamente definiti per fixture.nativeElement.offsetWidth e xBordersTotalWidth . Quindi calcoli la differenza tra i due. La tua affermazione dovrebbe quindi verificare se i risultati attesi sono venuti fuori. Ciò eviterà la duplicazione che hai menzionato e quindi ti proteggerà anche dalla duplicazione dei calcoli errati nel codice di test (e quindi non testando veramente il risultato atteso). Ad esempio, se hai definito il tuo dispositivo in modo che fixture.nativeElement.offsetWidth fosse 310 e xBordersTotalWidth fosse 10, dovresti scrivere le tue aspettative come:

expect(page.canvasEl.width).toEqual(300);

Direi che il tuo problema è che setCanvasRect sta facendo due cose: sta entrambi analizzando una proprietà e impostando le proprietà sul canvas. Dividi l'analisi in una funzione / classe / qualsiasi, quindi puoi testare separatamente le due cose:

1. Verifica che parseBorders(element) restituisca correttamente i bordi per l'elemento dato (potrebbe forse rompere questo ancor più nel prendere lo stile e analizzarlo).
2. Verifica che setCanvasRect(w, h) imposti correttamente l'altezza e la larghezza.
3. Verifica che setCanvasRect(element) compia le chiamate corrette a parseBorders(element) e setCanvasRect(w, h) , prendendo in giro le chiamate a parseBorders(element) e setCanvasRect(w, h) .

The coupling I am talking about is where tests are validating the state of the SUT, but have to mirror the code in order to gather the necessary data to form the assertion.

TL; DR: il termine di ricerca che desideri esplorare è property based testing .

Ciò che hai incontrato è un problema comune con i test basati su "esempi"; abbiamo un input noto, e quindi un output specifico che stiamo prendendo di mira, e se applichiamo abbastanza refactoring "remove dupation" nel codice di test, finiamo per scoprire l'implementazione che stiamo cercando di verificare.

I test basati sulle proprietà sono un'idea diversa: possiamo fare progressi con i test che controllano che le risposte abbiano le proprietà giuste, senza preoccuparsi troppo delle specifiche.

Scott Wlaschin ha scritto un'introduzione che mi piace molto, con i tentativi di scrivere test che costringono un avversario patologico a fornire una corretta implementazione di add(x,y) .

L'idea di base è di scavare intorno a cose che dovrebbero sempre essere vere: larghezza / altezza sempre di > = 0? saranno sempre meno delle estensioni dell'elemento nativo? la differenza sarà sempre un multiplo di due? Se l'altezza dell'elemento nativo è maggiore della larghezza, vuol dire che l'altezza della tela prevista è sempre maggiore della larghezza della tela prevista? e così via.

È in qualche modo analogo al trattamento delle post-condizioni nella progettazione per contratto; puoi verificare che il risultato dell'operazione soddisfi una collezione di invarianti?

Potresti anche estrarre la parte di calcolo in una funzione pura, approssimativamente in questo modo:

setCanvasRect() {
    let rootEl = this.elRef.nativeElement;
    let bordersWrapperStyle = getComputedStyle(rootEl);

    let widthAndHeight = calculateWidthAndHeight(
        bordersWrapperStyle.getPropertyValue('border-width'),
        rootEl.offsetWidth,
        rootEl.offsetHeight);

    this.canvasEl.width = widthAndHeight[0];
    this.canvasEl.height = widthAndHeight[1];
}

calculateWidthAndHeight(bordersWidth, rootOffsetWidth, rootOffsetHeight) {
    let bordersWidthElems = bordersWidth.split(' ')
    let yBordersTotalWidth = parseInt(bordersWidthElems[0]) * 2;
    let xBordersTotalWidth = parseInt(bordersWidthElems[1]) * 2;
    return [rootOffsetWidth - xBordersTotalWidth, rootOffsetHeight - yBordersTotalWidth];
}

Quindi puoi testare con esempi concreti

expect(calculateWidthAndHeight("10 5", 100, 200).toEqual([80, 190])