Caricamento ...
Spiacenti, si è verificato un errore durante il caricamento del contenuto.
 

dubbi filosofici su metodologia e testing

Espandi messaggi
  • Fabio Sogni
    Salve a tutti, sbircio sempre questo gruppo e non dico mai niente, ancora non ho dimestichezza col DDD e la maggior parte degli interventi per me sembrano
    Messaggio 1 di 124 , 16 apr 2013
      Salve a tutti,
      sbircio sempre questo gruppo e non dico mai niente, ancora non ho
      dimestichezza col DDD e la maggior parte degli interventi per me
      sembrano scritti in aramaico. Quindi abbiate pazienza per quanto vado a
      scrivere.

      Tempo fa mi ero imbarcato sulla ML di grails in una discussione
      filosofica sul testing (ciao zio brando). Vorrei riprenderla qui anche
      perche' nel frattempo i miei dubbi sono aumentati.
      Riverso qui tutti i miei dubbi invece di fare tanti post separati,
      magari negli eventualy reply potete affrontare un punto cambiando il
      soggetto.

      Tutto e' comincianto quando ho avuto la malaugurata idea ;) di vedermi
      tutti i video disponibili di Greg Young. Da quel momento non ho piu'
      dormito tranquillo. Ma ecco i miei dubbi:

      1) Ho un applicazione grails e ho installato cobertura. Quanto e' una
      percentuale ragionevole di copertura coi tests?
      In separata sede qualcuno mi ha risposto "100%" altri invece "stai
      scherzando? deve essere del 110%. minimo".
      Ecco voi cosa dite? Anche perche' per passare dall'87% al 100% ci sto
      impiegando un'infinita' di tempo. Segno che ho sbagliato qualcosa nel
      modello? Oppure e' giusto che la copertura sia asintotica?

      2) La business logic della mia applicazione grails e' tutta relegata nei
      servizi. In questo modo con gli integration tests riesco a testare
      tutto, cioe' quasi (vedi punto 1). Orbene, in un video di Young (sorry
      proprio non mi ricordo quale) il soggetto se ne esce con: "scommetto che
      voi relegate tutto nei servizi eh? bene, questa non e' programmazione ad
      oggetti".
      Mi devo sparare?

      3) Per il momento ho solo integration tests e praticamente zero unit
      tests. Ovviamente l'esecuzione mi dura una vita e ho deciso di tornare
      all'ovile e scrivere gli unit. Nell'occasione faccio refactoring e mi
      trovo di fronte metodi di servizio farciti di accessi al database,
      metodi con dentro cose tipo:

      // find permission
      Permission permission = Permission.createCriteria().get {
      eq('permissionType', permissionType)
      eq('active', true)
      eq('user', delegateUser)
      eq('externallyVisible', true)
      eq('resource', run)
      }

      L'idea e' estrarre le query e metterle in metodi del tipo
      findPermission(permissionType, delegateUser, run).
      Metterei addirittura questi medoti in un altro servizio chiamato chesso'
      PersistenceService (i metodi sarebbero usati da altri servizi).
      In questo modo negli unit test potrei mockare questi metodi, o l'intero
      servizio e far ritornare a findPermission quello che voglio.
      Questo non e' ulteriormente un degrado della programmazione a oggetti?
      (vedi punto 2).

      4) Ho menzionato la parola refactoring e in un video Young dice che
      aveva proposto di fare refactoring e un collega gli ha risposto "ottima
      idea, io riscrivo i tests". Young ha sbottato "cambiare i tests?! Questo
      non e' refactoring, questo e' refucktoring!".
      Ecco...che vuol dire? Se io faccio refactoring capita che debba cambiare
      i metodi, magari cambiando la signature o quello che ritornano.
      I test falliranno e che cosa faro' con questi test falliti? non mi e'
      chiaro.


      5) Mi sono messo d'impegno, ho fatto refactoring, ho scritto migliaia di
      unit tests e integration tests. Ho ridotto tutto all'osso e alla fine
      cobertura mi dice che ho il 99% di coverage del mio codice.
      Quell'uno per cento e' rappresentato da metodi del tipo:

      void sendPdfMail(EmailWithAttachment emailWithAttachment) {

      try {
      mailService.sendMail {
      multipart true
      to emailWithAttachment.to
      from emailWithAttachment.from
      if (emailWithAttachment.bcc) {bcc emailWithAttachment.bcc}
      subject emailWithAttachment.subject
      body emailWithAttachment.body
      attachBytes emailWithAttachment.pdfTitle,
      'application/pdf', emailWithAttachment.pdfReport
      }
      } catch (Exception e) {
      String errMsg = "Failed to send email"
      log.error(errMsg, e)
      //return "${errMsg}: ${e.message}"
      throw new RuntimeException(e)

      }
      }


      Oppure metodi di due righe che ritornano un file PDF generato con renderPdf.
      Orbene, devo perdere il sonno per quell'1%? Io posso anche invocare
      questi metodi e gabbare cobertura, ma come faccio a verificare che la
      mail e' partita o che il pdf e' generato correttamente? Al di la' delle
      questioni tecniche che ingegnandomi posso risolvere, ma proprio come
      metodo ha senso voler testare questi metodi a tutti i costi visto che
      comunque il nostro gruppo di testing verifica l'invio della mail e la
      generazione del PDF ?

      6) Per motivi che non sto ad approfondire il mio modello e' molto
      anemico, con le classi di dominio che sono praticamente dei POGOs, i
      controller sono magrissimi e tutto e' stipato nei servizi.
      Avrei bisogno di citazioni, magari autorevoli, magari al di fuori della
      Santa Chiesa del DDD che vada contro questo modo di fare, che dica
      chiaro e tondo che in Grails le domain classes non *devono* per forza
      essere dei POGOs. Questo mi serve per...uh...instaurare una dialettica
      all'interno del gruppo.

      Grazie mille per l'attenzione!

      ---------------------------------------------------------------------
      Fabio Sogni | E-Mail: fsogni@... |
      ESO - EUROPEAN SOUTHERN OBSERVATORY | Phone : +49 89 320 06 566 |
      Karl Schwarzschild Strasse, 2 | Fax : +49 89 320 06 677 |
      Garching bei Muenchen - Germany | |
      ---------------------------------------------------------------------
      Visita Interiora Terrae, Rectificando Invenies Occultum Lapidem.
      ---------------------------------------------------------------------
    • Alberto Brandolini
      Scopro ora che quella cosa aveva un nome. :o) In realtà, quando hai le cose davanti agli occhi, le idee ti vengono. Brando Il giorno 31 maggio 2013 18:42,
      Messaggio 124 di 124 , 31 mag 2013
        Scopro ora che quella cosa aveva un nome. :o)

        In realtà, quando hai le cose davanti agli occhi, le idee ti vengono.

        Brando


        Il giorno 31 maggio 2013 18:42, Arialdo Martini <arialdo.martini@...> ha scritto:
         


        2013/5/31 Alberto Brandolini <alberto.brandolini@...>
        Io in realtà faccio una cosa più in linea con il fatto di essere il proprietario occulto della 3M. Ragionamento  stile CRC cards. Appena è chiaro lo si butta su Whiteboard come collaboration diagram. Si scrivono i prossimi test come post-it che si appiccicano ai morsetti sul diagramma. Si torna al codice, fermandosi se ci sono cose che non tornano.

        E per esperienza personale, posso garantire che Alberto su questo è un maestro.
        Io non smetterò mai di ringraziarlo per avermi insegnato quella tecnica che Michael Feathers chiama Naked CRC e che dice di aver imparato da Ron Jeffries.


      Il tuo messaggio è stato inviato correttamente e verrà recapitato a breve ai destinatari.