Γενικά και χωρίς να ισχυρίζομαι οτι γνωρίζω πολλά επί του θέματος, εκτιμώ οτι η γενική ιδέα είναι: "Γράψε πρώτα τα τεστ και μετά τον κώδικα που κάνει τα τεστ να πετυχαίνουν".
Σε καταστάσεις οπου υπάρχει σωστή ανάλυση και σχεδίαση του λογισμικού, και, ακόμα περισσότερο, παγιωμένη αρχιτεκτονική χωρίς "ανακαλύψεις" της τελευταίας στιγμής, πιστεύω οτι όχι απλά βοηθά την ανάπτυξη, την εκτοξεύει.
Δυστυχώς όμως, εδώ, σε αυτή τη χώρα (και οχι μόνο, υποψιάζομαι), οπου ΔΕΝ υπάρχει συνήθως κανενός είδους ανάλυση, αρκετοί οίκοι λογισμικού ξεκινούν με τον κώδικα "και οπου βγει", οι προδιαγραφές αλλάζουν on the fly στη μέση του project, και το παραδοτέο πιέζεται από υπερβολικά μικρούς χρόνους γιατί κάποιος manager αποφάσισε σε συννενόηση με κάποιον πελάτη που τον πιέζει ο δικός του πελάτης οτι έτσι πρέπει να γίνει (χωρίς να έχει γνώση της προόδου του έργου), εννοιες όπως test-driven development που απαιτούν χρόνο και σωστή οργάνωση πάνε περίπατο.
Προσωπικά δοκίμασα το nUnit κάνοντας ένα ψιλο-unit testing μια φορά, όταν το project ήταν "παρθένο" και δεν είχα άγχος. Με βοήθησε πολύ να γράψω πρωτα τα tests τα οποία επαληθεύονταν από (σχεδιασμένο εκ των προτέρων) κώδικα. Οταν όμως οι απαιτήσεις αλλαξαν και οι προδιαγραφές άρχισαν να μεταβάλλονται γιατί υπήρχαν διαφοροποιήσεις των απαιτησεων του πελάτη, τα πράγματα δυσκόλεψαν. Ο χρόνος ήταν περιορισμένος και δεν μπορούσα να τον αναλωσω σε tests τα οποία μπορεί να έβγαιναν obsolete από τη μια μέρα στην άλλη.
Αρα λοιπον, προσωπική μου άποψη είναι οτι αν χρησιμοποιείς ένα σωστό και παγιωμένο domain model, έχεις σχεδιάσει πράγματα σε κάτι πριν αρχίσεις να γράφεις κώδικα (π.χ. UML diagrams, use cases κλπ) και έχεις σαφή εικόνα της αρχιτεκτονικής που θα χρησιμοποιήσεις σε διάφορα επίπεδα (π.χ. χρησιμοποιούμε DAAB και log4net, παει τελείωσε) τότε εχει νόημα. Αλλιώς....φοβάμαι πολύ.
Σωτήρης Φιλιππίδης
DotSee Web Services