Unit Testing

[LiTTle]

Καλησπέρα σε όλους,

Αυτή την περίοδο διαβάζω (ολοκληρώνω είναι το σωστό ρήμα) ένα βιβλίο για το JUnit και διάφορα άλλα εργαλεία για Unit Testing. Το βιβλίο είναι το "Manning JUnit in Action 2nd Edition". 

Είναι κάπως παλιό, το είχα όμως στη βιβλιοθήκη εδώ και πολύ καιρό για να το διαβάσω, αλλά προτίμησα το Android τότε, και τώρα δεν ήθελα να πάρω άλλο!

Στο μυαλό μου έχω ως εικόνα το Unit test ως έναν "χρήστη" του συστημάτος μου. Ομολογώ πως η χρήση του είναι απαραίτητη, μου αρέσουν τα datasets όπως χρησιμοποιούνται, το in-container testing πολύ ωραίο. 

Όμως, το βιβλίο χρησιμοποιεί interfaces με annotations. Δημιουργεί υποκλάσσεις της test runner κλάσσης για να διαβάζει τις annotations. Βάζει EL μεσα σε XML αρχεία ώστε να μην έχουμε πρόβλημα κατά το τεστάρισμα μιας DB. Κάνει όλες αυτές τις "υπερβολές" ενώ έχει περιγράψει και πιο απλούς τρόπους. Για εκπαιδευτικούς λόγους κάνει καλά και δε το κατακρίνω.

Ας επανέλθω όμως στην αγορά. Άραγε ένα Unit test αντί να είναι εντελώς απλό και να μας αποδεικνύει ότι όλα πάνε καλά, πρέπει να έχει τόσο "βαρύ" σχεδιασμό? Ή να τολμήσω να πω, σχεδιασμό με τόσο "εφέ"? Είναι απαραίτητα όλα αυτά τα extra συναρτήσει του χρόνου και του κόπου, για να αποδείξω πως η μέθοδος addUser(...) πράγματι δουλεύει?

Μήπως τελικά το Unit Testing χρησιμοποείται όσο και τα διαγραμμάτα UML? Σπάνια έως...καθόλου?

[Kostas Mourtzoukos]

Το κατά πόσο χρησιμοποιείται, είναι θέμα κάθε εταιρίας (θα δεις από το καλύτερο και το χειρότερο).

το κατά πόσο ΘΑ ΕΠΡΕΠΕ να χρησιμοποιείται, δεν τίθεται θέμα. Πάντα.

Αλλά ανάλογα που δουλεύεις, your mileage may vary που λένε.

cheers.

2013/3/6 LiTTle <littl...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "jhug" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhug+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
To err is human.
To really mess things up you need a computer
----
Save our in-boxes! http://emailcharter.org

[Ioannis Foukarakis]

Κατά τη γνώμη μου θα έπρεπε να επιβάλλονται:) Από εκεί και πέρα, όπως είπε και ο Κώστας, είναι θέμα της πολιτικής της κάθε εταιρίας, αλλά και του developer. Εγώ παλιότερα προσπαθούσα να γράφω unit tests όσο είχα χρόνο, αλλά τον τελευταίο  χρόνο η εταιρία που εργάζομαι το απαιτεί (και καλά κάνει). Μάλιστα πριν δώσω το dev complete, πρέπει να έχω code coverage > 80%. Φυσικά - όπως είπε κάποιος στο τελευταίο meeting - τα tests πρέπει να είναι πραγματικά, και όχι πατέντες (π.χ. απλά τρέχουμε τον κώδικα για να ανεβάσουμε το coverage). Ένα άλλο πλεονέκτημα που θα έχεις είναι ότι αν ο κώδικάς σου τεστάρεται εύκολα, τότε είναι μια ένδειξη ότι είναι καλογραμμένος. Υπάρχουν και άλλα πολλά, φαντάζομαι θα τα λέει και το βιβλίο που διαβάζεις.

2013/3/6 Kostas Mourtzoukos <mouri...@gmail.com>

[Thomas Pliakas]

Καλησπέρα και από εμένα,
  αυτό που περιγράφεις υποθέτω ότι καλύπτει όλα τα επίπεδα του testing. Συνήθως το "unit test" δεν αφορά τον "χρήστη" του συστήματός .. αλλά ουσιαστικά με το unit test κάνεις ελέγχους σε μικρα κομμάτια του κώδικά σου αυτόνομα (method level), έτσι ώστε να επιβεβαιώσεις ότι η υλοποίηση σου είναι σωστή, απλή (στο μέτρο του δυνατού) και να ελαχιστοποιούντια τα πιθανά προβλήματα.

Γενικώς το testing ενός συστήματος έχει πάρα πολλά επίπεδια (component, service, etc), και καλό έιναι να γίνεται έτσι ώστε να ελαχιστοποιουνται τα προβλήματα πρίν αυτό φτάσει στον πελάτη.

Στις μεγάλες εταιρείες, το testing είναι πολύ σοβαρή υπόθεση και συνήθως όλοι είναι υποχρεωμένοι να γράφουν unit/component/integration/etc ... tests, πριν ολοκληρώσουν κάποιο task που έχουν αναλάβει (εξαρτάται από τα process τις εταιρείας). Σε μεγάλα projects πολλές εταιρείες έχουν φτιάξει και τα δικά τους frameworks.

Κατά την γνώμη μου δεν είναι κάτι που πρέπει να υποτιμάται ... είναι ουσία.

Χαιρετώ
Θωμάς ...

2013/3/6 LiTTle <littl...@gmail.com>

[Evangelos Pappas]

Καλησπέρα,

Και Unit tests & UML χρησιμοποιούνται. Δεν πιστεύω πως μπορεί να υπάρξει ρεαλιστικό έργο δίχως υποστήριξη και documentation (ακόμα και σε υποτυπώδεις επίπεδα). Σχετικά με τα Unit tests η προσωπική μου εμπειρία μου έχει αποδείξει πως ειναι υπερεκτιμημένα. Σίγουρα πρέπει να υπάρχουν και πρέπει να γράφονται για καθε method που γράφεται και μάλιστα πολλά τεστς ανα μέθοδο ανάλογα με το complexity. Ο "μύθος" που υποστηρίζω πως υπάρχει ειναι εαν πρέπει να βασίζεσαι μονο σε στατιστικά των unit tests.

Ένα Unit test δεν θα σου δείξει ποτε ενα λογικό ή business logic σφάλμα (να μην μιλήσω για security). Και το χειρότερο, ειναι ακόμα πιο δύσκολο να γραφτεί test που να δοκιμάζει τέτοιου είδους περιπτώσεις. Με λίγα λόγια το γνωστό 80% coverage δεν θα έπρεπε να είχε τόσο αξία. 

Κατα την γνώμη μου ειναι γενικότερα λάθος να αφήνεις τον developer που έγραψε την μέθοδο/Κλάση να την δοκιμάζει. Πόσες φορες θα έχετε δει άστοχα assertNotNull() και assertSame() ή λάθος δομημένα Mocks. Σε κάθε περίπτωση όμως τα τεστς αυτά θα πέρναγαν και το coverage θα ήταν το επιθυμητό 80%, αλλα τα bugs θα έμεναν.

cheers,

Ε.Π.

2013/3/6 Thomas Pliakas <tpli...@gmail.com>

[Ioannis Foukarakis]

Το coverage από μόνο του δε λέει τίποτα. Είναι ένα όριο για να βάλεις τους developers (ή όποιον είναι υπεύθυνος) να τα γράψουν. Σίγουρα μπορεί να έχεις 10 test cases για το ίδιο κομμάτι κώδικα αν αυτό έχει ιδιαιτερότητες (γι' αυτό εξ' άλλου υπάρχουν πολλοί διαφορετικοί τρόποι να υπολογίσεις το coverage).

Κάτι που είναι σημαντικό είναι τι είναι τα unit tests. Προσωπικά πιστεύω ότι ένα unit test πρέπει να είναι μικρό και να δοκιμάζει μία μόνο κλάσση. Με αυτόν τον τρόπο  θα εξετάσεις ένα κομμάτι της λογκής ή του business logic, και όχι το σύνολο. Αυτό είναι διαφορετικού είδους testing, αλλά επειδή μπορείς να το κάνεις (και) με το JUnit πολύς κόσμος το μπερδεύει για unit test.

Επίσης σίγουρα θα υπάρξουν και λανθασμένα ή ελλειπή tests, αλλά αυτός δεν είναι λόγος για να μην γράφεις tests.  Είναι σα να λες ότι δε θα ξαναδιαβάσεις ένα κείμενο που έγραψες γιατί είσαι σίγουρος ότι και να το διορθώσεις, θα σου έχουν ξεφύγει ορθογραφικά λάθη. Αυτό που σου προσφέρουν είναι μια επιπλέον σιγουριά ότι έχεις ξανακοιτάξει τον κώδικά σου και το έχεις διπλοελέγξει. Επίσης είναι και ένας καλός τρόπος για να ειδοποιήσεις κάποιον ότι ο κώδικας που άλλαξε μπορεί μεν να κάνει αυτό που ήθελε, αλλά χάλασε κάτι άλλο.

2013/3/6 Evangelos Pappas <papas.e...@gmail.com>

[Patroklos Papapetrou]

Καλησπέρα και από μένα

Καταρχάς για το βιβλίο. Είναι ένα εξαιρετικό βιβλίο - αν και παλιό, ακόμα επίκαιρο - για να μάθει κανείς JUnit και τις επεκτάσεις τoy ( DBUnit, HtmlUnit κτλ. ) . Θα πρότεινα αν θέλεις να μάθεις ακόμα περισσότερα για το Unit Testing τα εξής παρακάτω : 

Effective Unit Testing -> http://www.manning.com/koskela2/

xUnit Test Patterns -> http://www.amazon.com/xUnit-Test-Patterns-Refactoring-Code/dp/0131495054

ή ακόμα και να δεις πως επηρεάζει το unit testing την ποιότητα του κώδικα και του λογισμικού 

Sonar In Action -> http://www.manning.com/papapetrou/ ( για να ευλογήσω και τα γένια μου )

Σχετικά με το Unit Testing, θα συμφωνήσω σε μερικά με τους προλαλήσαντες και σε άλλα θα διαφωνήσω. Έχουμε και λέμε:

Α) Δεν νοείται εν έτη 2013 να υπάρχει developer που να μην ξέρει να γράφει unit tests. Δεν νοείται εν έτη 2013 να κάνεις commit τα αρχεία σου χωρίς τα αντίστοιχα unit tests. Δεν νοείται εν έτη 2013, τα unit tests να μην είναι αυτοματοποιημένα ( βλ, Continuous Integration Systems ) και σε κάθε failure να ενημερώνεται ο "υπαίτιος". Αρα εν κατακλείδι τα Unit tests πρέπει να γίνονται από τον ίδιο developer που γράφει τον κώδικα.

Β) Το coverage δεν είναι το παν και ούτε αυτοσκοπός. Είναι όμως μια εξαιρετική ένδειξη για το πόσο καλά είναι ελεγμένος ο κώδικας. Να μη ξεχνάς ότι υπάρχουν και τρία διαφορετικά είδη coverage : Line Coverage, Branch Coverage, Overall coverage , τα οποία σου δίνουν ελαφρώς διαφορετικές πληροφορίες.

Γ) Για να γράψεις σωστά unit tests πρέπει καταρχάς να κατανοείς το τι πρέπει να κάνει ο κώδικας ώστε να τεστάρεις τα σωστά πράγματα. Για αυτό το λόγο το Test Driven Development κερδίζει συνεχώς έδαφος. Αν ο κώδικάς σου δεν κάνει τα σωστά κι εσείς τεστάρεις τη συμπεριφορά του και όχι την ΑΝΑΜΕΝΟΜΕΝΗ συμπεριφορά ( σε business context ) τότε τα unit tests είναι δεν σου παρέχουν όλα τα καλούδια τους.

Δ) Πάμε παρακάτω: Integration Tests ( Acceptance Tests, UI Tests, DB Tests κτλ., ), Όλα είναι (σχεδόν) άχρηστα αν δεν υπάρχει ουσιαστικό o coverage από Unit Tests. Άρα πρώτα ξεκινάμε από τα unit και μετά συνεχίζουμε προς τα πάνω. 

Ε) Τέλος, η σύγκριση με τα UML διαγράμματα είναι λίγο άστοχη και εξηγώ. Όταν βρίσκεις ένα bug πριν το διορθώσεις καλό είναι να γράψεις ένα unit test που πιάνει το Bug και αποτυγχάνει. Μετά διορθώνεις το bug και το unit test "πρασινίζει". Στα παραπάνω βήματα προφανώς και δε χρειάζεται να χρησιμοποιήσεις UML. Τι θέλω πω: Τα unit tests πρέπει να αποτελούν καθημερινότητα ενός developer ενώ η UML συνήθως όχι.

ΣΤ) Σταματάω εδώ διότι δε θα τελειώσω :) 

Αυτά τα λίγα 

Ελπίζω να βοήθησα

Patroklos Papapetrou

Co-Author of Sonar in Action

http://gr.linkedin.com/in/ppapapetrou

http://twitter.com/ppapapetrou76

[Kostis Kapelonis]

Χαιρομαι για αυτήν την ερώτηση!

Θα μπορουσα να καθίσω να αναλύσω τις απόψεις μου για το θέμα σε απειρα
emails, αλλά δεν χρειάζεται πια γιατί τα έβαλα όλα σε blogs posts!

http://zeroturnaround.com/labs/why-your-next-cloud-app-will-probably-suck-without-unit-testing/

http://zeroturnaround.com/labs/dont-test-blindly-the-right-methods-for-unit-testing-your-java-apps/

http://zeroturnaround.com/labs/how-to-mock-up-your-unit-test-environment-to-create-alternate-realities/

http://zeroturnaround.com/labs/the-correct-way-to-use-integration-tests-in-your-build-process/

Και ορίστε και άλλο ένα μικρό bonus

http://zeroturnaround.com/labs/using-spock-to-test-groovy-and-java-applications/

2013/3/6 Patroklos Papapetrou <ppapap...@gmail.com>:

[Antonios Chalkiopoulos]

Ελπίζω το μύνημα μου να μην θεωρηθεί κακο-προαίρετο, αλλά το θέμα της συζήτησης είναι σχετικό..

Αρχικά να πώ ότι θεωρώ πολύ σημαντικό το testing όσο και το automation του, κάτι που δεν συζητήθηκε αρκετά.

Και εννοώ ότι όποια JUnit / Regression ή Integration Testing σενάρια θα πρέπει να εκτελούνται αυτόματα 

κατά την διαδικασία του build. Δηλαδή με την χρήση ενώς εργαλείου όπως το Jenkins μπορούμε να έχουμε

κάποιο hook στο repository ώστε κάθε φορά που ένας developer κάνει commit νέο κώδικα, τα junit καθώς

και όποιαδήποτε άλλα tests θα πρέπει να εκτελούνται στον continuous integration server για να αναδείξουν

οποιαδήποτε σφάλματα στον κώδικα.

Επίσης ιδιαίτερα σημαντικό στις ημέρες του web & mobile app development είναι το Integration testing. Έστω

ότι για ένα application έχουμε δημιουργήσει μια σειρά από APIs. Κάθε API μπορεί να έχει γίνει internally tested

με junit αυτό όμως δεν αποδεικνύει ότι μια αλληλουχία API calls θα συμπεριφερθεί as expected. Και τι εννοώ

Έστω ότι έχουμε ένα API για το χρήστη να κάνει login. Μετά ένα άλλο API του επιτρέπει να postarei μια φωτό.

Ένα ακόμα API του επιτρέπει να διαγράψει την φωτογραφία αυτή με την προυπόθεση ότι κανένας άλλος χρήστης

δεν έχει προσθέσει για παράδειγμα κάποιο comment στην φωτογραφία αυτή. Τα backend που προσφέρουν τα APIs

μπορεί να είναι σε διαφερετικά cloud-instances. Ελέγχοντας λοιπόν το κάθε API ξεχωριστά, δεν μας επιβεβαιώνει

ότι η αλληλουχία των API θα δουλέψουν as expected. Η λύση σε αυτό είναι το integration testing όπου συμπεριφορές

ενώς χρήστη θα γίνουν simulated ώστε να έχουμε την βεβαιώτητα για την πλήρη λειτουργικότητα της εφαρμογής μας.

Επίσης συμφωνώ με τον Κώστα σχετικά με το 'πολιτική της εταιρίας'. Θέλοντας να μιλήσω για εμένα που λειτουργώ

εδώ και 1.5 χρόνο μια εταιρία software-development στο Λονδίνο έχοντας 3-4 άτομα στην ομάδα μας, και υλοποιούμε 

μια start-up εφαρμογή με περίπου 70.000 γραμμές Java so-far: 

αυτό που παρατηρώ είναι ότι δίνουμε προτεραιότητα σε feature development παρά σε Quality Control, με αποτέλεσμα το code coverage να είναι σχετικά χαμηλά...

Έτσι αυτό που θέλω να ρωτήσω εδώ είναι κατά πόσο κάποιος ενδιαφέρεται για το testing και για μια συνεργασία μαζί μου/μας.

Μιλάω για work-from-home κατάσταση, όπου κάποιος θα απασχολείται περίπου 10 ώρες / εβδομάδα. Ενδιαφέρομαι να

συνεργαστώ με οποιονδήποτε και δεν με απασχολεί αν είναι φοιτητής ή κάτι άλλο και βλέπω προοπτική συνεργασίας πολλών μηνών.

Από πλευράς development βλέπω ότι θα ασχοληθούμε με junit/integration/regression/load/selenium testing και στην πορεία σαν ομάδα 

θα μπούμε και σε Big Data υλοποιήσεις για Hadoop περιβάλλοντα, καθώς έχω κάποιο domain knowledge λόγω της εργασίας μου. 

Θέλω σε γενικά γραμμές κάποιον που να θέλει να κάνει java backend development & testing. 

Θεωρώ ότι η συνεργασία αυτή θα είναι πολύ ώραία και παρακαλώ στείλτε μου κάποιο εμαιλ όποιος ενδιαφέρεται. 

Για να είμαι ξεκάθαρος και στο οικονομικό, το ποσό που μπορώ να διαθέσω είναι στα περίπου 300 ευρώ μηνιαίως.

Αναμένω εμαιλ από όποιον ενδιαφέρεται να μπεί στην ομάδα μας, και ζητώ συγνώμη αν το μύνημα μου δεν είναι appropriate για μια λίστα σαν αυτή.

Φιλικά, Αντώνης

[Paris Apostolopoulos]

Γεια σου Αντώνη καταρχήν πολυ ωραίος για την internal προσφορά εργασίας - +1 . Είναι κάτι το οποίο χαιρόμαστε να το βλέπουμε μέσα απο τις επικοινωνίες του jhug (οποιαδηποτε μορφής)

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

 Το πρόβλημα μπορεί να δημιουργηθεί  πίσω στην ομάδα σου. Αν η ομάδα σου μάθει σε αυτό το mode ότι υπάρχει κάποιος ο οποίος θα κάνει και αυτό τότε on the long run αν δεν προσπαθήσεις να εντάξεις σε οποιο βαθμό μπορείτε το unit testing σαν mentality ..τότε χάνεις ένα μικρό μοχλό πίεσης αλλά και έναν λόγο οι ίδιοι oi developer να σκεφτούν την ορθότητα του κώδικα τους.

Αυτό που βλέπω από την δική μου εμπειρία που τις πιο πολλές φορές γράφω unit test μετά την υλοιποίηση (έχουμε πει αρκετά για αυτή την στρεβλωση ) είναι ότι έστω και έτσι, βλέπω προβλήμα σε μια υλοποίηση μου και εστω μετά από λιγο καιρό αλλάζω τον κώδικα μου προς το καλύτερο - σίγουρα προς το  πιο modular!

Το πρόβλημα με κάποιιον που ειναι εκτός της core ομάδας είναι ότι μπορεί πχ εγώ να ξεκινήσω να γράφω unit test και πάνω στην διαδικασία θα ανακαλύψω σχεδικαστικά προβλήματα στον τρόπο γραφής (δεν ξέρω το κώδικα σου απλά σου λέω από δική μου εμπειρία), θα μπορεί να εχει το ελευθερο και την εμπειράι αλλά και το know how να αλλάξει το under test κώδικα!

Όπως και να εχει πιο πολυ ήθελα να σε προβληματίσω με το παραπάνω με 2 βασικά πράγματα1
1. off shoring unit testing ...σε βάθος χρόνου δεν χτίζεις decipline στην ομάδα σου αλλά και ευκαιρίες για να βελτιώθεί
2. o εξωτερικός συνεργάτης θα μπορεί να κάνει αλλαγές αρχιτκτονικής του κώδικα που πιθανά θα αναδείξουν τα όποια unit / code base integration test?

Ευχαριστω και χαιρετισμούς από Ελλάδα!

[Ioannis Foukarakis]

Νομίζω ότι έχουμε ανοίξει μια πολύ ωραία συζήτηση, που δεν θα ήταν άσχημη ιδέα να τη συνεχίσουμε σε κάποιο meeting;) Σίγουρα υπάρχουν αρκετά εργαλεία που έχει χρησιμοποιήσει ο καθένας μας για να αντιμετωπίσει διαφορετικά προβλήματα. Οπότε μόνο και μόνο η καταγραφή τους θα ήταν ένα ωραίο output από το group. Και μάλιστα κάτι καινούργιο σε σχέση με τις (άριστες) έως τώρα παρουσιάσεις.

2013/3/10 Paris Apostolopoulos <java...@gmail.com>

[Ioannis Canellos]

Εχώ διαβάσει με πολύ μεγάλο ενδιαφέρον τις απόψεις, αλλά κάπου νιώθω ότι ακόμα και αυτοί που υπερασπίζονται τα unit tests τα παρουσιάζουν σαν "το πλύσιμο τον πιάτων" (αγγαρία που δεν την γουστάρεις αλλά ΠΡΕΠΕΙ να την κάνεις).

Μια μικρή και ελπίζω σχετική προσωπική εμπειρία:

Το αντικέιμενο τις πρώτης μου δουλειάς ήταν ένα swing application σχετικό με άσφάλεις (αυτοκινήτου, ζωής κτλ). Κανείς στη δουλειά δεν χρησιμοποιούσε καμία μορφή αυτόματου testing, κανείς δεν μου μίλισε ποτέ γιαυτά και δεν γνώριζα την ύπαρξή τους. Ακόμα και στην πιο μικρή αλλάγή που γινόταν στο application, έπρεπε να κάνω rebuild και relaunch την εφαρμογή και να κάνω ότι θα έκανε και ο χρήστης (data entry δηλαδή μέχρι να φτάσω στο σημείο που αφορά την αλλάγη που έκανα). Στην καλυτερη των περιπτώσεων η αλλαγή μου ήταν σωστή και με μεγάλη χαρά πήγαινα στο επόμενο task. Μερικές φορές όμως ένα χαζό λαθάκι με ανάγκαζε να κάνω ξανά rebuild/relaunch κ.ο.κ. Άλλες φορές το λαθάκι ήταν λογικό σφάλμα και έπρεπε να κάνω μια μεγαλύτερη αλλαγή, η οποία όμως επηρέαζε και πράγματα που είχα τεστάρει μια ώρα πριν (πράγμα που σημαίνει ότι θα έπρεπε να ξανατεστάρω και εκείνα).

Μετά τους πρώτους μήνες δουλειάς μου ήτανε ξεκάθαρο ότι αυτό είναι εντελώς αντιπαραγωγικό και ότι θα έπρεπε να υπάρχει ένας πιο έξυπνος τρόπος ώστε να μπορώ να δώ άμεσα το impact μιας αλλαγής που έχω κάνει. Τότε μου ήρθε η ιδέα του να χρησιμοποιήσω ένα macro recorder, για να κάνω λίγο πιο αυτόματα το data entry πού έκανα με το χέρι. Η ιδέα δεν ήταν τόσο κακή όσο μπορεί να ακούγεται. Έιχε όμως το βασικό μειονέκτημα ότι ήθελε τον ίδιο ακριβώς χρόνο (με λίγοτερο βέβαια κόπο).  Τότε άρχισα να πιστεύω ότι το ίδιο πρόβλημα θα είχαν και άλλοι developers και ότι θα έπρπε να υπάρχει κάποια καλύτερη λύση, η οποία τελικά όντως υπήρχε και αυτή ήτανε τα unit tests.

Η δυνατότητα του να μπορώ με εύκολο και γρήγορο τρόπο να testάρω ότι μια μέθοδος που κάνει κάτι πάρα πολύ απλό, όντως κάνει αυτό που θέλω, για μένα είναι εργάλειο productivity.

--
Ioannis Canellos

Blog: http://iocanel.blogspot.com

Twitter: iocanel

[Anestis Georgiadis]

+1 για το Spock σε Java apps.
+1000 για unit testing in general/principle/practice/whathaveyou.

άσχετη ερώτηση: Κωστή πως την παλεύεις ακόμη με το Eclipse? :-)

--
Anestis Georgiadis
Software architect, amateur photographer, aspiring cyclist
http://about.me/mranest

[Yoryos]

Ας πω λοιπόν και εγώ την άποψή μου...

Κρατάω μόνο την τελευταία παράγραφο από τον Ιωάννη. Πιστεύω είναι ο ορισμός του unit test και ο κύριος λόγος για να το χρησιμοποιείς ως developer. 

Ως side effects με unit tests έχεις και άλλα καλούδια που οδηγούν τις περισσότερες φορές σε καλύτερο modularity του κώδικα (όπως είπε και ο Πάρης). Όμως αυτά είναι "άχρηστα" για τον μη τεχνικό μιας και δεν δίνουν κάτι επιπλέον στο προϊόν. Η μέθοδος που τεστάρεις μπορεί να αλλάξει η να διαγραφεί τελείως κάποια στιγμή. Το ίδιο και το αντίστοιχο unit test. 

Αυτό όμως που θα μήνει είναι ένα integration test που αν γίνει σωστά μπορεί να περιγράφει όλα τα specs του project. Αυτό για εμένα παίζει το σημαντικότερο ρόλο, είναι αυτό που πρέπει να έχει κάθε project και είναι αυτό που θα πρέπει να γράφει από senior developer όσο το δυνατόν πιό νωρίς σε ένα project. Αν είναι δυνατόν πριν αρχίσει το καθαρό implementation. Φυσικά είναι και το πιο δύσκολο της υπόθεσης :)

~Γιώργος

2013/3/10 Ioannis Canellos <ioc...@gmail.com>

[Evaggelos Sinapidis]

Γεια σας κι από μένα!

Το Testing και όχι απλά το Unit Testing είναι κάτι που επέβαλα στην δουλειά μου καθώς ουσιαστικά μου δίνει την ευκολία να ξέρω κατά πόσο μετά από μια αλλαγή ή ένα refactoring δεν έχει επηρεαστεί η εφαρμογή.

Στην καθημερινή "μόνιμη" δουλειά χρησιμοποιούμε κατά κύριο λόγο απλά unit tests και κάποια integration tests, τα οποία επιβάλλονται από την εταιρία. Βέβαια πολλά από αυτά (δικά μου ή άλλων) είναι απλά dummy για να ανεβάζουν το coverage rate. Αλλά υπάρχει από πίσω και τμήματα QA που θα εκτελέσει κι αυτό από την δικιά του πλευρά τα tests κτλ. Οπότε στο τέλος έχουμε πάντα ένα software που παίζει κατά 90+%. Το 10% που λείπει χωρίζεται σε ένα 2% που είναι λάθη develop που δεν έπιασε κανένα test και ένα 8% που είναι λάθος "μεταφρασμένο" business. Το τελευταίο είναι και το κύριο πρόβλημα που παρουσιάζεται στην εταιρία που δουλεύω. Αλλά η διαδικασία που περιέγραψα είναι μια εξαίρεση ας πούμε, γιατί μας δίνεται αρκετός χρόνος για dev και test, υπάρχουν αρκετά καλές προδιαγραφές, επιβάλλονται διάφορες διαδικασίες που ανεβάζουν το quality του προϊόντος  Πράγματα που στις περισσότερες ελληνικές εταιρίες δεν ισχύουν.

Από την άλλη, στις υπόλοιπες δουλειές που αναλαμβάνω σαν freelancer, δεν μπορούν να ισχύσουν όλα τα παραπάνω. Γιατί τα project είναι μικρά και πρέπει να βγουν στην παραγωγή γρήγορα, γιατί ο πελάτης δεν έχει ιδέα τι είναι το documentation, τα specs κτλ και πολλές φορές με το ζόρι ξέρει τι θέλει. Οπότε στις περιπτώσεις αυτές δεν μπορώ ούτε κατά διάνοια να χρησιμοποιήσω "κλασσικό" unit testing. Αλλά για να μπορέσω να εξασφαλίσω μια ψυχική ηρεμία και μία ποιότητα έπρεπε να βρω μια ενδιάμεση κατάσταση. Να τεστάρω γρήγορα και άμεσα ότι κάτι δουλεύει. Γι αυτό το λόγο χρησιμοποίησα το Arquillian ( http://arquillian.org ) που μου δίνει ένα γρήγορο τρόπο να οργανώσω logical tests. Με το εργαλείο αυτό και με την πάροδο του χρόνου αναπτύσσω, ας πούμε, ένα δικό μου test framework ή ας το θέσουμε πιο απλά μια δικιά μου διαδικασία testing που με καλύπτει. Και μπορώ να πω με σιγουριά ότι μετά από 3 project που το έχω ξεκινήσει αυτό, βλέπω μια συνεχή βελτίωση της ποιότητας του έργου που παραδίδω και μεγαλύτερη ταχύτητα στην ανάπτυξη του.

[Markos Fragkakis]

"Βέβαια πολλά από αυτά (δικά μου ή άλλων) είναι απλά dummy για να ανεβάζουν το coverage rate"

Αυτό μου θυμίζει κάτι γιαγιάδες που στα γεράματα ξεκινάνε να πηγαίνουν εκκλησία...

2013/3/11 Evaggelos Sinapidis <vande...@gmail.com>

--

You received this message because you are subscribed to the Google Groups "jhug" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jhug+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Sent from my iPhone

[Paris Apostolopoulos]

Μάρκο -> Δείξε μου έναν developer που δεν το έχει κάνει (δηλαδή να γίνει γιαγιά) και θα ντυθώ γιαγιά τις απόκριες.

 Στην καριέρα μου/μας έχω ακούσει και μου έχει ζητηθεί μερικες φορές παράλογα requirement πχ κάνε unit/test  σε κώδικα process engine, δηλαδή να δω αν πράγματι το process engine υλοποιεί την βασική του λογική - δηλαδή αν πηγαίνει το state machine από ένα state στο άλλο, δηλαδή το αυτονόητο...δηλαδή γέρασα πριν την ώρα μου.

Μερικές φορές οι developers από καλή διάθεση φέρνουν το θέμα της ποιότητας μόνοι τους στο τραπέζι του project και αυτό γίνετια misuse από άτομα τα οποία δεν μπορουν να κατανοήσουν για το τι πράγμα μιλάμε.

Ναι, είμαι από αυτούς υποστηρίζω τους developers γενικά (όχι γιατί είμαι ένας από αυτούς) αλλά γιατί θεωρώ ότι ήταν και είναι οι key players σε κάθε έργο..άσχετα αν έχουμε άλλη τύχη!

Viva la liberation χαχα.

[Antonios Chalkiopoulos]

Εγώ στην φιλοσοφική συζήτηση μπορώ να σου απαντήσω σχετικά με τη δικιά μου εμπειρία.

Η ομάδα μας είναι 100% offshore, άλλος στην Αθήνα, άλλος στο Λονδίνο, άλλος στα Χανιά και άλλος στην Jakarta.

Έχοντας μια τέτοια απομακρυσμένη σχέση ήταν απαραίτητο για εμάς να εντάξουμε όλα τα κατάλληλα εργαλεία

που θα κάνουν capture τα requirements (confluence) plan & monitor το work-in-progress (Jira), artifact repository (Nexus),

continuous testing & integration (Jenkins) και όλα τα απαραίτητα - distibuted source control κτλ 

Στο γεγονός ότι εσύ ή οποιοσδήποτε θα βρεί μετά από λίγο καιρό τον κώδικα και θα εντοπίσει σημεία προς βελτίωση,

σαν μέλος μιας agile ομάδας σαφώς θα κουβεντιαστεί και θα δωθεί χρόνος για το κατάλληλο refactoring. 

Η προσωπική μου εμπειρία είναι ότι κάθε τι σε μια νεο-συσταμένη εταιρία - νεοσύστατη ομάδα θα γίνει 

refactor περίπου 3 φορές μέχρι να είναι όλοι happy

και ως παράδειγμα να πώ για το απλό Maven που ξεκινά από ένα pom.xml και καταλήγει να έχεις parent pom και κατόπιν και pom modules

ή ακόμα ένα στην περίπτωση μας που παίζουμε με GWT & AppEngine από RPC -> RequestFactory -> JSon APIs με AutoBean & gson

Για την συγκεκριμένη ανάγκη που έχουμε θέλαμε κάποιος να κάνει drive το testing effort.. και αφού μπεί στην φιλοσοφία του

app να κάνει και backend development..

Για να μεταφέρω και κάποιες εμπερίες από ομάδες testing εδώ.. καλά λόγια ακούγονται για το Cucumber

On Wednesday, 6 March 2013 14:01:05 UTC, LiTTle wrote:

[Alexandros Papadakis]

Δεν ξέρω κατά πόσο έχετε υπόψη σας το παρακάτω:

http://www.codinghorror.com/blog/2006/01/code-reviews-just-do-it.html

Η σούμα είναι:

.. software testing alone has limited effectiveness -- the average defect detection rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for integration testing. In contrast, the average effectiveness of design and code inspections are 55 and 60 percent. Case studies of review results have been impressive:

• In a software-maintenance organization, 55 percent of one-line maintenance changes were in error before code reviews were introduced. After reviews were introduced, only 2 percent of the changes were in error. When all changes were considered, 95 percent were correct the first time after reviews were introduced. Before reviews were introduced, under 20 percent were correct the first time.
• In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80 percent.
• The Aetna Insurance Company found 82 percent of the errors in a program by using inspections and was able to decrease its development resources by 20 percent.
• IBM's 500,000 line Orbit project used 11 levels of inspections. It was delivered early and had only about 1 percent of the errors that would normally be expected.
• A study of an organization at AT&T with more than 200 people reported a 14 percent increase in productivity and a 90 percent decrease in defects after the organization introduced reviews.
• Jet Propulsion Laboratories estimates that it saves about $25,000 per inspection by finding and fixing defects at an early stage.

Και αναρωτιέμαι: Αν μια εταιρεία δεν έχει την "πολυτέλεια" να έχει και unit testing και code reviews , αν πρέπει δηλαδή να επιλέξει το ένα ή το άλλο, τι είναι καλύτερο να κάνει;

Αλέξανδρος 

2013/3/11 Antonios Chalkiopoulos <ant...@gmail.com>

[Markos Charatzas]

Αλέξανδρε παραβλέπεις ένα μεγάλο κομμάτι του testing που έχει να κάνει με formal contracts, regressions και automation.

Έστω ότι γράφεις μία μέθοδο που πολαπλασιάζει 2 αριθμούς. Εφόσον δεν έχεις ένα test να την επιβεβαιώνει, δεν ξέρεις αν δουλεύει.

Kάνεις code review και την βρίσκεις σωστή. 

Μέχρι το επόμενο review, αποφασίζεις να αλλάξεις την υλοποίηση με πρόσθεση. 

Αυτόματα είσαι επίπονος σε regression. Κάνεις commit και το integration fails. Δεν έχεις automated tests.

Αρκετά έχουν γραφτεί για το κόστος που χρειάζεται να φτιάξεις κώδικα στα διάφορα στάδια του development και πόσο αυτό αυξάνεται στα μετέπειτα.

[Alexandros Papadakis]

Αν δουλευεις μόνος σου, και κανεις commit μόνος σου, παίρνεις και ένα build και το πας παραγωγή,  τότε ναι, έχεις θέμα...

Αν και φαντάζομαι ότι το λιγότερο που θα έπρεπε να κάνεις είναι μια δοκιμή αν αυτό που "έγραψες" δουλεύει.. ή απλώς κάνει... compile... (και αν σε παίρνει, κάντο και unit test)

Μιλάω για code-review τύπου fork & pull. Δηλάδη για να μπει ο κώδικας στο repo, πρέπει να τον δει και άλλος ένας και να δώσει το ΟΚ.

Έχει κανείς εμπειρία σε κάτι τέτοιο;

Alex

2013/3/22 Markos Charatzas <markos.c...@gmail.com>

[Dionisis Petrakopoulos]

Καλημέρα και από εμένα,

Στο τελευταίο που γράφει ο Αλέξανδρος για code review έχουμε μια αντίστοιχη διαδικασία αλλά δεν γίνεται πριν μπει ο κώδικας στο repo αλλά μετά.

Απλά ενώ έχεις ήδη κάνεις commit και έχει περάσει φυσικά ο κώδικας σου από CI (unit tests και remote build, χρησιμοποιούμε το TeamCity), κάνεις ένα meeting για code review για να κλείσει το action item. Εκεί απλά συζητάτε για τον κώδικα σου και απλά μπορεί να σου πουν να διορθώσεις κάποια πράγματα όπως hidden dependencies, duplicate code κλπ.

Τα σημειώνεις, κάνεις τις διορθώσεις και το commit σου και μετά κλείνει το action item.

Απλά να τονίσω ότι αυτή η διαδικασία δεν εχεί καμία σχέση με το unit testing το οποίο έχεις κάνει ήδη πριν πας στο code review. Ουσιαστικά στο code review παίρνεις το OK για να κλείσεις το action item.

Διονύσης

2013/3/22 Alexandros Papadakis <alp...@gmail.com>

[Antonios Chalkiopoulos]

Code review tipou fork & pull exoun s e arketa projects sto git hub.

Sto scalding p.x. kaneis fork to git repository - paizeis kai ftiaxneis to commit sou kai to pushareis sto diko sou fork tou repo

Katopin kaneis pull request sto official repo apo opou kai ekanes originally to fork kai ekei

o lead tou project sou kanei comment (p.x. allakse to onoma tis methodou se X, kai vale ti tade methodo ekei)

Epistrefeis sto diko sou fork opou kaneis tis allages kai katopin ananewneis to pull request - opou k ginetai approve

Swsti diadikasia - alla thelei dedicated team leader pou na kanei review ta panta..