Ciao, premettendo che nei miei casi i test end-to-end erano dalla API in giù; per testare query, transazioni, casi limite e simili mi sono trovato bene a creare dei db effimeri con docker, usando [0]. Ad ogni test o suite un nuovo db veniva creato da docker e poi popolato con flyway-db (anche io avevo spring-boot); potevo metterci anche dei set di dati predefiniti controllando opportunamente le API/properties/profili di spring-boot/flyway-db.
Concordo sul fatto che test così larghi vadano creati quando davvero serve e non per manie di grandezza. [0] https://github.com/palantir/docker-compose-rule Il giorno 1 febbraio 2018 18:26, Gavino Pintus [email protected] [it-torino-java-jug] <[email protected]> ha scritto: > > > Ciao ragazzi, > Sto lavorando con un applicativo che ha Angular 4 a frontend e spring boot > a backend. > > Ho iniziato a scrivere test end to end utilizzando protractor. Il tutto > funziona bene, ma scrivendo davvero sul db (che é il db in memory hsql), il > problema è che i test a volte vanno ed a volte no perché alla fine del > processo non fanno rollback. > > Voi come avete risolto questo tipo di problemi? Ci sono delle best > practice in merito? > > Grazie > > Il 31 gen 2018 19:29, "Uberto Barbini [email protected] > [it-torino-java-jug]" <[email protected]> ha scritto: > > > > Come tutte le cose cqrs può fare molto danno se usata male. > A Londra va di moda da un po' ed è già pieno di progetti nei guai. :) > > Btw all ddd exchange parlerò di cqrs funzionale. > > Uberto > > On 31 Jan 2018 12:58, "Matteo Vaccari [email protected] > [it-torino-java-jug]" <[email protected]> wrote: > > > > poter rimuovere le bieche responsabilita' di lettura dai tuoi oggetti di > dominio e' un'epifania che libera la mente per soluzioni piu' potenti e > semplici, indipendentemente dall'architettura finale > > > Ma che bella maniera di dirlo :) > > > 2018-01-28 0:26 GMT+01:00 Carlo Bottiglieri [email protected] > [it-torino-java-jug] <[email protected]>: > > > > Ma che bel thread. > > Solo una nota e poi torno a lurkare: CQRS e Event Sourcing vengono > spiegati e soprattutto usati assieme perche' assieme ti portano ai sistemi > eventually-correct ad alte performance che tanto bene si adattano alle > applicazioni commerciali di massa. Ha perfettamente senso, pero' trovo che > nasconda un po' il valore concettuale di CQRS: poter rimuovere le bieche > responsabilita' di lettura dai tuoi oggetti di dominio e' un'epifania che > libera la mente per soluzioni piu' potenti e semplici, indipendentemente > dall'architettura finale. > CQRS+ES e' un bel meccanismo elegante, ma CQRS da solo e' un nuovo grado > di liberta' quando definisci un qualunque ingranaggio, quindi e' meglio non > incasellarlo solo con ES. > > > On Sat, Jan 27, 2018 at 12:50 PM max carbone [email protected] > <[email protected]> [it-torino-java-jug] < > [email protected]> wrote: > > > > > Command-Query Responsibility Segregation > > > Mi sento a casa :) Noi lo usiamo in combinazione con Event Sourcing (Axon > nell specifico come implementazione). > > > Ignorante che sono, ho "scoperto" il pattern CQRS solo di recente, > anch'io combinato al pattern Event Sourcing (ref.: http://microservices.io > /patterns/data/cqrs.html ). > > Bye. max > > > -- > 'Electric lamps were not invented by improving candles' > > > > >
