Design & Architecture

Re: Test Driven Development

cap — Thu, 05 May 2005 23:26:32 GMT

Εκανα ένα γρήγορο test drive στο mbUnit επειδή έτυχε να έχω ένα project που να "κολλάει" με τη χρήση του για ορισμένα γρήγορα test.

Δυστυχώς (και μετά από κουβέντα και με τον pkanavos) διαπίστωσα οτι το Rollback feature "παίζει" μόνο σε win2003. Που σημαίνει οτι οποιος πτωχός έχει 2000 server (οπως εγώ στη δουλειά) δεν έχει τη δυνατότητα να το αξιοποιήσει.

Παντως σαν feature είναι από πολύ ως πάαααρα πολύ χρησιμο! Να μια αιτία να γυρίσω γρήγορα στα 2003! Ειναι γενικά πολύ πληρέστερο από το nUnit, και το θέλω, το θέλω, το θέλω!

(Ναι γιατρε, θα απεξαρτηθώ... )

Εμμένω πάντως στην αρχική μου άποψη ως προς το test-driven development.

Re: Test Driven Development

Παναγιώτης Καναβός — Thu, 05 May 2005 18:09:00 GMT

Χρησιμοποιώ το MbUnit τον τελευταίο καιρό και το βρίσκω ΚΑ-ΤΑ-ΤΑ-ΠΛΗΚΤΙΚΟ!
Το MbUnit χρησιμοποιεί custom attributes για να μαρκάρει τις κλάσεις και τις μεθόδους που χρησιμοποιούνται για test, καθώς και τί είδους τεστ είναι. Ένα από αυτά είναι και ... το [Rollback] το οποίο μαρκάρει μία μέθοδο και κάνει rollback ότι αλλαγές έχει κάνει, σε οποιαδήποτε βάση! Αυτό το καταφέρνει επειδή το RollbackAttribute χρησιμοποιεί Enterprise Services για να ξεκινήσει ένα transaction πριν εκτελεστεί η μέθοδος και κάνει rollback όταν τελειώσει. Υπάρχουν επίσης και το [SqlRestoreInfo] και [RestoreDatabaseFirst] που χρησιμοποιούνται σε συνδιασμό για να κάνουν backup την αρχική μορφή μιας βάσης και να την κάνουν restore πριν τρέξει κάθε test.

To MbUnit, πακέτο με addin για το Visual Studio θα το βρεις στο http://www.testdriven.net/ . Source και άρθρα θα βρεις στο http://mbunit.tigris.org . Υπάρχει και ένα άρθρο που περιγράφει το [Rollback]

Το παρακάτω (χοντροκομμένο) παράδειγμα δείχνει πως μπορείς να χρησιμοποιήσεις το [Rollback] και την κλάση DataAssert για να εκτελέσεις test στη βάση και να συγκρίνεις τα αποτελέσματα:

 
using System;
using System.Data;
using System.Data.SqlClient;
using MbUnit.Core.Framework;
using MbUnit.Framework;
using MyRealNamespace;

 
namespace MyTestNameSpace
{
   [TestFixture]   public class MyTests
   {
      [Test]
      [RollBack]      public void ASimpleTest()
      {
         DataSet expectedSet=LoadMyExpectedSet();
         MyRealClass realObject=new MyRealClass();
         DataSet actualSet=realObject.LoadCustomers();
         DataAssert.AreDataEqual(expectedSet,actualSet);


         
         realObject.DeleteAllCustomers();

         Assert.AreEqual(0,realObjec.CustomerCount);


      }
   }

}

Re: Test Driven Development

cap — Thu, 05 May 2005 17:59:16 GMT

Γενικά και χωρίς να ισχυρίζομαι οτι γνωρίζω πολλά επί του θέματος, εκτιμώ οτι η γενική ιδέα είναι: "Γράψε πρώτα τα τεστ και μετά τον κώδικα που κάνει τα τεστ να πετυχαίνουν".

Σε καταστάσεις οπου υπάρχει σωστή ανάλυση και σχεδίαση του λογισμικού, και, ακόμα περισσότερο, παγιωμένη αρχιτεκτονική χωρίς "ανακαλύψεις" της τελευταίας στιγμής, πιστεύω οτι όχι απλά βοηθά την ανάπτυξη, την εκτοξεύει.

Δυστυχώς όμως, εδώ, σε αυτή τη χώρα (και οχι μόνο, υποψιάζομαι), οπου ΔΕΝ υπάρχει συνήθως κανενός είδους ανάλυση, αρκετοί οίκοι λογισμικού ξεκινούν με τον κώδικα "και οπου βγει", οι προδιαγραφές αλλάζουν on the fly στη μέση του project, και το παραδοτέο πιέζεται από υπερβολικά μικρούς χρόνους γιατί κάποιος manager αποφάσισε σε συννενόηση με κάποιον πελάτη που τον πιέζει ο δικός του πελάτης οτι έτσι πρέπει να γίνει (χωρίς να έχει γνώση της προόδου του έργου), εννοιες όπως test-driven development που απαιτούν χρόνο και σωστή οργάνωση πάνε περίπατο.

Προσωπικά δοκίμασα το nUnit κάνοντας ένα ψιλο-unit testing μια φορά, όταν το project ήταν "παρθένο" και δεν είχα άγχος. Με βοήθησε πολύ να γράψω πρωτα τα tests τα οποία επαληθεύονταν από (σχεδιασμένο εκ των προτέρων) κώδικα. Οταν όμως οι απαιτήσεις αλλαξαν και οι προδιαγραφές άρχισαν να μεταβάλλονται γιατί υπήρχαν διαφοροποιήσεις των απαιτησεων του πελάτη, τα πράγματα δυσκόλεψαν. Ο χρόνος ήταν περιορισμένος και δεν μπορούσα να τον αναλωσω σε tests τα οποία μπορεί να έβγαιναν obsolete από τη μια μέρα στην άλλη.

Αρα λοιπον, προσωπική μου άποψη είναι οτι αν χρησιμοποιείς ένα σωστό και παγιωμένο domain model, έχεις σχεδιάσει πράγματα σε κάτι πριν αρχίσεις να γράφεις κώδικα (π.χ. UML diagrams, use cases κλπ) και έχεις σαφή εικόνα της αρχιτεκτονικής που θα χρησιμοποιήσεις σε διάφορα επίπεδα (π.χ. χρησιμοποιούμε DAAB και log4net, παει τελείωσε) τότε εχει νόημα. Αλλιώς....φοβάμαι πολύ.

Test Driven Development

Panagiotis Kontopoulos — Thu, 05 May 2005 17:37:35 GMT

Τον τελευταίο καιρό διάβασα 1-2 βιβλία για TDD και πιστεύω ότι έχει να προσφέρει πολλά σε όλους όσους ασχολούνται με το development.

Το πρόβλημα μου όμως είναι ότι τα παραδείγματα που αναφέρονται σε αυτά τα βιβλία ασχολούνται κυρίως με αλγόριθμους που επεξεργάζονται δεδομένα στη μνήμη ή εκτελούν κάποιες μαθηματικές πράξεις. Δεν έχω βρει κάποια αναλυτικά παραδείγματα για εφαρμογές που διαχειρίζονται δεδομένα σε βάσεις δεδομένων, ξέρετε βασικές ή περισσότερο πολύπλοκες CRUD εφαρμογές.

Και όσο να πεις έχει μια δυσκολία να στήσεις μια σειρά καλών Tests cases για διαχείριση δεδομένων σε βάση. Μερικά θέματα είναι : Πρέπει να αφήσεις τη βάση όπως ήταν στην έναρξη των δοκιμών για να μπορέσεις να ξανατρέξεις τα ίδια tests ξανά και ξανά, οι περισσότεροι έλεγχοι σου σχετίζονται με συγκεκριμένες τιμές που πρέπει να βρίσκεις στη βάση, Identity κλειδιά, Master-Detail πίνακες κλπ.

Εχει κάποιος κάποια εμπειρία στο θέμα? Links, βιβλία, samples ?
Και γενικότερα ποια είναι η άποψη σας για το Unit Testing/Test Driver Development?
Καλό/Κακό/Απαραίτητο/Αχρηστο ?