Εργασία ως προγραμματιστής υπό δύσκολες συνθήκες

[tsofras]

25 λεπτά πριν, albNik είπε

Στην πραξη ειναι πιο περίπλοκο. Το feature λεει οτι τωρα οταν καλεις το a θα εκτελεις τα x'y'z' αντι για xy που ηταν πριν. Στα τεστ δεν ειναι τοσο ευκολη η αντικαταστάση xy-->x'y'z'. Όσο περισσότερα τεστ τόσο πιο δυσκολα

To test υπάρχει γιατί αν η μέθοδος που είχες έκανε x + y τότε τεσταρει ότι δουλεύει το x + y  . Αν έβαλες στην μέθοδο να κάνει και + z , τότε καλά κάνει το τεστ και σκάει και πρέπει να το φτιάξεις και αυτό.

Και είσαι τυχερός αν βρίσκεται σε codebase που έχει χιλιάδες tests γιατί όταν αλλάζεις κάτι γνωρίζεις ότι κάτι έσπασες

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

[albNik]

3 ώρες πριν, tsofras είπε

To test υπάρχει γιατί αν η μέθοδος που είχες έκανε x + y τότε τεσταρει ότι δουλεύει το x + y  . Αν έβαλες στην μέθοδο να κάνει και + z , τότε καλά κάνει το τεστ και σκάει και πρέπει να το φτιάξεις και αυτό.

Και είσαι τυχερός αν βρίσκεται σε codebase που έχει χιλιάδες tests γιατί όταν αλλάζεις κάτι γνωρίζεις ότι κάτι έσπασες

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

Και ποιος θα τεσταρει το τεστ οτι τεσταρει σωστα το x+y 😃 

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

 

[tsofras]

16 λεπτά πριν, albNik είπε

Και ποιος θα τεσταρει το τεστ οτι τεσταρει σωστα το x+y 😃 

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

 

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

Το βράδυ όμως που τρέχεις την σουίτα σου είσαι ήσυχος ότι όλα είναι όπως πρέπει

Έχω πετύχει και προγραμματιστές που βλέπουν τεστ να σκάνε και τα φτιάχνουν απλά για να περάσουν δεν έχει να λέει κάτι αυτό

Η λογική είναι να γράφεις σωστά τεστ για να έχεις το κεφάλι σου ήσυχο

[Kercyn]

18 λεπτά πριν, albNik είπε

Και ποιος θα τεσταρει το τεστ οτι τεσταρει σωστα το x+y 😃 

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

 

Γι' αυτό γράφεις πρώτα το test 😛

Ελέγχεις συμπεριφορά, όχι υλοποίηση. Ναι σίγουρα μπορεί να έχεις περίπλοκα use cases και σίγουρα μπορεί να γίνει λάθος, αλλά είναι μια ακόμη δικλείδα ασφαλείας πολύ πιο ισχυρή από το μυαλό του κάθε developer που θα ελέγξει την ορθότητα ενός κομματιού κώδικα με το μυαλό του.

[Papakaliati]

Τα unit testing ειναι μια αλλη πονεμενη ιστορια. Προφανως δεν υπαρχει 100% καλυψη, και αμα αυτο προσπαθεις κανεις κατι πολυ λαθως και σπαταλας χρονο και χρημα να το πουμε απλα. Τα unit testings ειναι ενα συμπληρωματικο εργαλειο, και σε καμια περιπτωση δεν πρεπει να θεωρουμε οτι αμα τρεχουν, τοτε ο κωδικας μας ειναι σωστος. Απλα σημαινει οτι τα cases που σκεφτηκαμε δουλευουν, ελα ομως τα cases που μπορουμε να σκεφτουμε ειναι αυτα που αμα το συστημα δουλεψει μια ωρα θα παρουσιαστουν ολα. Τα δυσκολα edge cases, που προκαλουν τον μεγαλητερο πονο ουτε καν συνηθως σου περνανε απο το μυαλο, και προφανως δεν καλυπτωνται απο unit testing. Σωστο και αναλυτικο exception handling ειναι πιο σημαντικο. 

Λίγα integration tests και λιγα unit tests και σωστο exception handling >>>> 100% unit test coverage. 

Bugs πάντα θα υπάρχουνε. Σωστο exception handling θα σε βοηθησει να εντωπισεις ευκολoτερα τα bugs. Ειδικα πλεον στα cloud services, με ολα τα hidden external dependencies. Integrations testing ftw. 

[ALLisCHAOS]

Στις 11/12/2020 στις 9:08 ΠΜ, Papakaliati είπε

Τα unit testing ειναι μια αλλη πονεμενη ιστορια. Προφανως δεν υπαρχει 100% καλυψη, και αμα αυτο προσπαθεις κανεις κατι πολυ λαθως και σπαταλας χρονο και χρημα να το πουμε απλα. Τα unit testings ειναι ενα συμπληρωματικο εργαλειο, και σε καμια περιπτωση δεν πρεπει να θεωρουμε οτι αμα τρεχουν, τοτε ο κωδικας μας ειναι σωστος. Απλα σημαινει οτι τα cases που σκεφτηκαμε δουλευουν, ελα ομως τα cases που μπορουμε να σκεφτουμε ειναι αυτα που αμα το συστημα δουλεψει μια ωρα θα παρουσιαστουν ολα. Τα δυσκολα edge cases, που προκαλουν τον μεγαλητερο πονο ουτε καν συνηθως σου περνανε απο το μυαλο, και προφανως δεν καλυπτωνται απο unit testing. Σωστο και αναλυτικο exception handling ειναι πιο σημαντικο. 

Λίγα integration tests και λιγα unit tests και σωστο exception handling >>>> 100% unit test coverage. 

Bugs πάντα θα υπάρχουνε. Σωστο exception handling θα σε βοηθησει να εντωπισεις ευκολoτερα τα bugs. Ειδικα πλεον στα cloud services, με ολα τα hidden external dependencies. Integrations testing ftw. 

Διαφωνώ. Εάν καθήσεις και καλύψεις κάθε πιθανή περιπτωση του function σου σε test cases τότε οι πιθανότητες να πάει κάτι στραβά σίγουρα λιγοστεύουν. Σαφώς και τέλειο (bugs free) software δεν υπάρχει. Σκοπός όμως είναι να το κάνουμε με όσο δυνατόν λιγότερα bugs γίνεται και το testing (unit tests + integration tests) βοηθάνε φουλ. Αυτό που έχω παρατηρήσει εγώ είναι ότι τις περισσότερες φορές το αίτιο για τα bugs είναι αυτο το ριμάδι το state του application μας το οποίο τις περισσότερες φορές επειρεάζει το output των function μας ή με 2 λόγια, δεν γράφουμε pure functions και χρησιμοποιούμε τόσο πολύ mutable data structures... Ένας λόγος που έχω αγαπήσει το functional programming + clojure είναι ότι προωθούν ακριβώς αυτό το στυλ, immutable data και pure functions! Το οποίο με τη σειρά του πιστεύω σε ωθεί σε ένα καλύτερο product με λιγότερα bugs 

[evark]

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