Asserzioni sulle views con Ruby On Rails e assert_select

Problema

Su Significato Canzone (un progetto laterale sul significato delle canzoni che porto avanti da diversi anni) ho introdotto un bug dopo la riscrittura con Javascript / Vue di una parte del frontend.

Ho tolto un semplice meccanismo scritto con jQuery e l’ho riscritta secondo le logiche di Vue. Il problema è che lo script jQuery in questione coinvolgeva altre pagine oltre a quella direttamente collegata alla riscrittura.

Nelle altre pagine non sto usando Vue.js perché la situazione è assai più semplice e lineare e una riscrittura al momento non avrebbe alcun senso. In sostanza non mi ero più ricordato delle altre pagine. Un tipico errore dovuto alla mancanza di test che assicurano di non rompere il codice pre-esistente. In generale la code base è sotto test ma non la parte che riguarda javascript.

Analisi sulle possibili soluzioni

Come evitare di continuare a perseverare nell’errore? Un test di sistema è la risposta più corretta poiché garantisce una completa copertura del caso di uso dell’utente.
Purtroppo da quando uso Docker non ho più avuto modo di ripristinare un corretto ambiente di sviluppo con i test di sistema e Rails.
Quindi al momento posso solo usare i test unitari e di integrazione che permettono la verifica dell’html e della logica delle pagina ma non della specifica corretta esecuzione del javascript.

Ho comunque deciso perlomeno di assicurarmi della presenza del js apposito e del data-attribute collegato allo script all’interno dell’html. Almeno sarò sicuro di aver dedicato uno script e un attributo apposito per la situazione. Per procedere con questa soluzione ho dovuto affrontare i test delle views col metodo assert_select.

Come si usa assert_select?

Il problema con assert_select è che lo conosco poco poiché lo uso di rado. Come detto in precedenza solitamente preferisco usare test di sistema come Cypress.io o Selenium che viene già incluso nel pacchetto di Rails.

Inoltre la prima soluzione che avevo trovato su stackoverflow non funzionava perché si riferiva a una soluzione possibile solo con Rails 4 e versioni precedenti. Fortunatamente la nota di un utente mi ha portato a capire il problema. Le api per fare affermazioni sugli attributi dei nodi html è infatti cambiata nelle ultime versioni e prevede una sintassi diversa. Leggermente più complessa ma più flessibile. Di seguito un esempio preso direttamente dalla mia code base che permette di fare asserzioni su data-attribute conosciuti solo in parte. Infatti una delle cose più difficili che ho dovuto affrontare è stato che il link allo script js viene generato ogni volta con un id diverso e quindi non è possibile testarlo in modo “statico”.

test 'show annotation need data attribute' do
  get annotation_path(annotations(:one))
  assert_select "#js-annotations[data-song=#{song.id}]"
  assert_select "script:match('src', ?)", /annotations.+/
end

Riassumendo

assert_select "script:match('src', ?)", /annotations.+/

La parte più rilevante del ragionamento è quindi questa riga dove l’asserzione si mescola con un operatore (match) e una espressione regolare (/annotations.+/). Insomma tre elementi per niente banali ma importanti poiché permettono di risolvere il problema.

Espressioni regolari, operatori nuovi (match) e il metodo assert_select sono strumenti che frequento di rado. L’occasione del bug mi ha dato l’occasione per ripassare e scoprire le novità di questo strumento (assert_select) che si rivela alla fine in ultima analisi assai flessibile e che forse dovrei frequentare più spesso 🙂