Ο οδηγός αυτός ξεκινά εκεί που τελειώνει ο οδηγός 4. Έχουμε φτιάξει μια εφαρμογή ψηφοφορίας (Web-poll application) και τώρα θα δημιουργήσουμε μερικά αυτοματοποιημένα τεστ για αυτήν.
\nΤα τεστ (tests) δεν είναι τίποτε άλλο παρά απλές ρουτίνες οι οποίες ελέγχουν τη λειτουργία του κώδικα σας.
\nΤο τεστ δραστηριοποιείται σε διαφορετικά επίπεδα. Μερικά τεστ μπορεί να εφαρμοστούν σε μια μικρή λεπτομέρεια (επιστρέφει μια συγκεκριμένη μέθοδος ενός μοντέλου τις αναμενόμενες τιμές;) ενώ άλλα εξετάζουν την συνολική εικόνα λειτουργίας του λογισμικού (παράγει το επιθυμητό αποτέλεσμα η σειρά των inputs ενός χρήστη στο site;). Αυτό δεν είναι κάτι διαφορετικό από το τεστ που κάνατε νωρίτερα στον Οδηγό 2, χρησιμοποιώντας την εντολή shell για να εξετάσετε τη συμπεριφορά των μεθόδων ή να τρέξετε την εφαρμογή και κατά την αλληλεπίδραση μαζί της, να δείτε πως συμπεριφέρεται.
Αυτό που διαφέρει στα αυτοματοποιημένα τεστ είναι ότι η δουλειά των τεστ γίνεται για σας από το σύστημα. Δημιουργείτε μια φορά ένα σετ από τεστ και μετά καθώς η εφαρμογή σας αλλάζει, μπορείτε να ελέγξετε ότι ο κώδικας σας δουλεύει όπως αρχικά είχατε σχεδιάσει χωρίς να χρονοτριβείτε με χειροκίνητα τεστ.
\nΓιατί, λοιπόν, δημιουργούμε τεστ και γιατί τώρα;
\nΊσως να αισθάνεστε ότι έχετε αρκετά στο κεφάλι σας ήδη (μαθαίνετε Python, μαθαίνετε Django) για να σας προστεθεί άλλη μια γνώση η οποία, σκέφτεστε, ίσως σας φανεί περιττή ή ακόμα και άχρηστη. Παρ’ όλ’ αυτά η εφαρμογή μας λειτουργεί περίφημα. Γιατί να μπούμε στον κόπο να φτιάξουμε αυτοματοποιημένα τεστ; Δεν θα κάνει την εφαρμογή μας καλύτερη, έτσι δεν είναι; Αν είναι να φτιάξετε μόνο αυτή την εφαρμογή με το Django και μετά δεν ασχοληθείτε άλλο, τότε ναι, δεν χρειάζεται να γνωρίζετε πως να φτιάξετε αυτοματοποιημένα τεστ. Αλλά αν δεν είναι έτσι, τώρα είναι μια καλή στιγμή να μάθετε πως.
\nΜέχρι ένα σημείο η λογική του “τεστάρω για να δω αν λειτουργεί” θα δουλεύει μια χαρά. Σε πιο εκλεπτυσμένες-περίπλοκες εφαρμογές μπορεί να έχετε δεκάδες, αν όχι εκατοντάδες, αλληλεπιδράσεις μεταξύ των οντοτήτων σας (models, views κλπ) και η παραπάνω λογική να μην μπορεί πλέον να σας φανεί χρήσιμη.
\nΜια αλλαγή σε μια από αυτές τις οντότητες μπορεί να έχει μη αναμενόμενα αποτελέσματα στη συμπεριφορά της εφαρμογής σας. Αν εφαρμόσετε την παραπάνω λογική του “φαίνεται να δουλεύει” ίσως χρειαστεί να ελέγξετε τον (και να ανατρέξετε στον) κώδικα σας με πάνω από είκοσι διαφορετικές εκδόσεις των τεστ δεδομένων σας, μόνο και μόνο για να σιγουρευτείτε ότι αυτή και μόνο η αλλαγή δεν επηρέασε αρνητικά κάποιο άλλο κομμάτι του κώδικα σας (κάποια άλλη οντότητα). Όλα αυτά χειροκίνητα - όχι και πολύ καλή αξιοποίηση του χρόνου σας.
\nΑυτό είναι αλήθεια όταν τα αυτοματοποιημένα τεστ μπορούν να κάνουν την παραπάνω δουλειά για εσάς, σε δευτερόλεπτα. Αν κάτι πάει στραβά, τα τεστ θα σας βοηθήσουν στην αναγνώριση του κώδικα που δεν είχε την αναμενόμενη συμπεριφορά (δεν έτρεξε, δηλαδή, όπως του είχατε υπαγορεύσει).
\nΚαμιά φορά ίσως σας φανεί ως αγγαρεία να ξεφύγετε από το παραγωγικό και δημιουργικό κομμάτι της δουλειάς σας μόνο και μόνο για να μπείτε στη διαδικασία γραφής των ανιαρών τεστ, ειδικά όταν γνωρίζετε ότι η εφαρμογή σας λειτουργεί ορθά.
\nΑπό την άλλη, το κομμάτι της συγγραφής των τεστ θα προσθέσει μεγαλύτερη αξιοπιστία στον κώδικα σας από το να τεστάρετε τον κώδικα χειροκίνητα ή να προσπαθείτε να αναγνωρίσετε τη πηγή ενός νεοεισερχόμενου προβλήματος.
\nΕίναι λάθος να νομίζετε ότι τα τεστ συμβάλλουν αρνητικά στην ανάπτυξη των εφαρμογών.
\nΦανταστείτε τους προγραμματιστές να μην είχαν στα εργαλεία τους τα τεστ. Χωρίς αυτά, ο στόχος ή η αναμενόμενη συμπεριφορά μιας εφαρμογής θα ήταν θολή-σκοτεινή. Ακόμα και αν είναι δικός σας κώδικας, θα χρειαστεί, μερικές φορές, να ψάξετε μέσα στον κώδικα για να διαπιστώσετε τι κάνει.
\nΤα τεστ τα αλλάζουν όλα αυτά. Φωτίζουν τον κώδικα σας από μέσα και όταν κάτι πάει στραβά, ξέρετε ακριβώς ποιο ήταν αυτό το κομμάτι, ακόμη και αν δεν είχατε συνειδητοποιήσει ότι αυτό το κομμάτι πήγε στραβά.
\nΜπορεί να έχετε δημιουργήσει ένα λογισμικό διαμάντι αλλά άλλοι προγραμματιστές αρνούνται να ρίξουν μια ματιά σε αυτό μόνο και μόνο επειδή στερείται τεστ. Χωρίς τεστ, δεν θα τον εμπιστευτούν. Ο Jacob Kaplan-Moss, ένας από τους αρχικούς προγραμματιστές του Django, λέει «Code without tests is broken by design.»
\nΠροκειμένου άλλοι προγραμματιστές (developers) να δουν σοβαρά το δικό σας software, θα πρέπει να έχετε υλοποιήσει (γράψει) τα απαραίτητα τεστ.
\nΟι προηγούμενες παράγραφοι γράφτηκαν από την σκοπιά ενός και μόνου developer ο οποίος διατηρεί ένα application. Οι περίπλοκες εφαρμογγές, όμως, θα διατηρούνται από ομάδες. Τα τεστ, εγγυώνται ότι οι συμμετέχοντες στην ομάδα δεν θα χαλάσουν (break) τον κώδικα σας ακούσια αλλά ούτε και εσείς θα χαλάσετε τον δικό του, ακούσια πάλι. Αν θέλετε να βγάλετε τα προς το ζην όντας ένας Django programmer, θα πρέπει να είστε καλός στη συγγραφή των τεστ!
\nΥπάρχουν πολλοί τρόποι για να προσεγγίσει κανείς τη συγγραφή των τεστ.
\nΚάποιοι προγραμματιστές ακολουθούν μια διαδικασία με το όνομα «test-driven development». Ξεκινούν να γράφουν τα τεστ προτού γράψουν τον κώδικα τους. Αυτό μπορεί να ακούγεται αντί-διαισθητικό αλλά στην πραγματικότητα οι περισσότεροι ακολουθούν αυτή τη μέθοδο: αρχικά περιγράφουν το πρόβλημα και κατόπιν γράφουν κώδικα για να το λύσουν. Η λογική της διαδικασίας test-driven development μπορεί να μεταφερθεί πανεύκολα στα test cases της Python.
\nΠιο συχνά, όσοι είναι νέοι στο χώρο των τεστ θα γράψουν πρώτα τον κώδικα και μετά θα αποφασίσουν ότι θα έπρεπε να είχαν γράψει μερικά τεστ. Ίσως θα ήταν καλύτερα να είχαν γραφτεί τα τεστ νωρίτερα, αλλά ποτέ δεν είναι αργά για να ξεκινήσει κανείς.
\nΜερικές φορές δεν ξέρεις πως να ξεκινήσεις να γράφεις τεστ. Αν έχετε γράψει μερικές χιλιάδες γραμμές Python κώδικα, είναι δύσκολο μετά να επιλέξεις κάτι για να γράψεις τεστ πάνω σε αυτό. Σε τέτοιες περιπτώσεις είναι πιο παραγωγικό να γράψετε το πρώτο σας τεστ κάθε φορά που κάνετε μια αλλαγή, είτε προσθέτετε κάποιο καινούργιο feature είτε διορθώνετε ένα bug.
\nΑς ξεκινήσουμε λοιπόν, αμέσως τώρα.
\nΕυτυχώς, υπάρχει ένα μικρό bug στην εφαρμογή μας (polls) και αξίζει να το διορθώσουμε ευθύς αμέσως: η μέθοδος Question.was_published_recently() επιστρέφει True αν η ερώτηση (Question) εκδόθηκε εντός εικοσιτεσσάρων ωρών (το οποίο είναι σωστό). Η ίδια μέθοδος επιστρέφει πάλι True αν το pub_date τοποθετείται στο μέλλον (κάτι το οποίο δεν μπορεί να ισχύει).
Confirm the bug by using the shell to check the method on a question\nwhose date lies in the future:
Linux / macOS
$ python manage.py shell\nWindows
...\\> py manage.py shell\n>>> import datetime\n>>> from django.utils import timezone\n>>> from polls.models import Question\n>>> # create a Question instance with pub_date 30 days in the future\n>>> future_question = Question(pub_date=timezone.now() + datetime.timedelta(days=30))\n>>> # was it published recently?\n>>> future_question.was_published_recently()\nTrue\nΕφόσον τα πράγματα στο μέλλον δε θεωρούνται “πρόσφατα”, τότε αυτό είναι ξεκάθαρα λάθος.
\nΌτι ακριβώς κάναμε στο shell για να τεστάρουμε το πρόβλημα, θα το κάνουμε στο αυτοματοποιημένο τεστ που θα γράψουμε αμέσως τώρα.
Ένα βολικό μέρος για να κρατάτε όλα τα τεστ για την εφαρμογή σας είναι σε ένα ξεχωριστό αρχείο με το όνομα tests.py. Το σύστημα (testing system) θα βρει αυτόματα όλα τα τεστ, αρκεί καθένα από αυτά να ξεκινούν με τη λέξη test.
Γράψτε τον ακόλουθο κώδικα στο αρχείο tests.py μέσα στην εφαρμογή polls:
import datetime\n\nfrom django.test import TestCase\nfrom django.utils import timezone\n\nfrom .models import Question\n\n\nclass QuestionModelTests(TestCase):\n\n def test_was_published_recently_with_future_question(self):\n """\n was_published_recently() returns False for questions whose pub_date\n is in the future.\n """\n time = timezone.now() + datetime.timedelta(days=30)\n future_question = Question(pub_date=time)\n self.assertIs(future_question.was_published_recently(), False)\nHere we have created a django.test.TestCase subclass with a method that\ncreates a Question instance with a pub_date in the future. We then check\nthe output of was_published_recently() - which ought to be False.
In the terminal, we can run our test:
\nLinux / macOS
$ python manage.py test polls\nWindows
...\\> py manage.py test polls\nκαι θα δείτε κάτι σαν αυτό:
\nCreating test database for alias 'default'...\nSystem check identified no issues (0 silenced).\nF\n======================================================================\nFAIL: test_was_published_recently_with_future_question (polls.tests.QuestionModelTests)\n----------------------------------------------------------------------\nTraceback (most recent call last):\n File "/path/to/mysite/polls/tests.py", line 16, in test_was_published_recently_with_future_question\n self.assertIs(future_question.was_published_recently(), False)\nAssertionError: True is not False\n\n----------------------------------------------------------------------\nRan 1 test in 0.001s\n\nFAILED (failures=1)\nDestroying test database for alias 'default'...\nΑυτά που συνέβησαν είναι τα εξής:
\nmanage.py test polls looked for tests in the polls application
βρήκε μια subclass της κλάσης django.test.TestCase
δημιούργησε μια ειδική database για τους σκοπούς του τεστ
έψαξε για τεστ μεθόδους - εκείνες των οποίων το όνομα ξεκινά με τη λέξη test
μέσα στην μέθοδο test_was_published_recently_with_future_question δημιούργησε ένα Question instance του οποίου το pub_date field είναι 30 μέρες στο μέλλον
… και χρησιμοποιώντας τη μέθοδο assertIs(), διαπίστωσε ότι η μέθοδος was_published_recently() επιστρέφει True, αντί για False
Το τεστ, μας ενημερώνει ποιο τεστ απέτυχε (τώρα έτυχε να έχουμε μονάχα ένα αλλά στο μέλλον δεν θα έχετε μόνο ένα) και ακόμη και την γραμμή του κώδικα στο τεστ όπου προέκυψε το failure.
\nΓνωρίζουμε ήδη ποιο και που είναι το πρόβλημα: η μέθοδος Question.was_published_recently() θα πρέπει να επιστρέψει False αν το pub_date τοποθετηθεί στο μέλλον. Βελτιώστε τη μέθοδο μέσα στο αρχείο models.py, ούτως ώστε να επιστρέφει True μόνο για παρελθοντικές ημερομηνίες:
def was_published_recently(self):\n now = timezone.now()\n return now - datetime.timedelta(days=1) <= self.pub_date <= now\nκαι τρέξτε τα τεστ ξανά:
\nCreating test database for alias 'default'...\nSystem check identified no issues (0 silenced).\n.\n----------------------------------------------------------------------\nRan 1 test in 0.001s\n\nOK\nDestroying test database for alias 'default'...\nΑφού βρήκαμε ένα bug, γράψαμε ένα τεστ το οποίο το αναδεικνύει και τέλος διορθώσαμε το bug στο κώδικα ούτως ώστε το τεστ να θεωρηθεί επιτυχές.
\nΥπάρχει πιθανότητα πολλά άλλα πράγματα να πάνε στραβά με την εφαρμογή μας στο μέλλον αλλά μπορούμε να είμαστε σίγουροι ότι αυτό το συγκεκριμένο bug δεν θα ξαναεμφανιστεί στον κώδικα μας, αφού όταν τρέξουμε την σουίτα των τεστ του Django θα μας ειδοποιήσει αμέσως. Με άλλα λόγια έχουμε κάνει την εφαρμογή μας πιο ασφαλή-σταθερή κατά ένα βαθμό.
\nΌσο είμαστε εδώ μπορούμε να βελτιστοποιήσουμε την μέθοδο was_published_recently() λιγάκι περισσότερο. Θα ήταν ντροπιαστικό, αν προσπαθώντας να διορθώσουμε ένα bug να έχουμε δημιουργήσει κάπου αλλού ένα άλλο (άθελα μας).
Προσθέστε δύο ακόμη μεθόδους τεστ στην ίδια κλάση, για να τεστάρουμε την συμπεριφορά της μεθόδου πιο περιεκτικά:
\ndef test_was_published_recently_with_old_question(self):\n """\n was_published_recently() returns False for questions whose pub_date\n is older than 1 day.\n """\n time = timezone.now() - datetime.timedelta(days=1, seconds=1)\n old_question = Question(pub_date=time)\n self.assertIs(old_question.was_published_recently(), False)\n\ndef test_was_published_recently_with_recent_question(self):\n """\n was_published_recently() returns True for questions whose pub_date\n is within the last day.\n """\n time = timezone.now() - datetime.timedelta(hours=23, minutes=59, seconds=59)\n recent_question = Question(pub_date=time)\n self.assertIs(recent_question.was_published_recently(), True)\nΤώρα έχουμε τρία τεστ, τα οποία επιβεβαιώνουν ότι η μέθοδος Question.was_published_recently() επιστρέφει λογικές τιμές για παρελθοντικές, παρούσες και μελλοντικές τιμές του pub_date.
Υπενθυμίζουμε ότι η εφαρμογή μας, polls είναι μια απλή εφαρμογή. Ωστόσο, στο μέλλον, όσο περίπλοκη και να γίνει και ο οποιοσδήποτε άλλος κώδικας (ίσως από άλλη δική μας εφαρμογή) αλληλεπιδράσει με την εφαρμογή αυτή, μπορούμε να εγγυηθούμε ότι η μέθοδος στην οποία έχουμε γράψει τα τεστ θα συμπεριφέρεται σε αναμενόμενα πλαίσια.
Η εφαρμογή μας, polls, δεν κάνει διακρίσεις! Θα κάνει publish οποιαδήποτε ερώτηση, συμπεριλαμβανομένων και εκείνων που το pub_date field βρίσκεται στο μέλλον. Θα πρέπει να το διορθώσουμε αυτό. Θέτοντας το pub_date στο μέλλον θα σημαίνει ότι η ερώτηση θα πρέπει να γίνει publish εκείνη την ημερομηνία αλλά θα είναι αόρατη μέχρι τότε.
Όταν διορθώσαμε το bug πριν, γράψαμε πρώτα το τεστ και μετά τον κώδικα για να διορθώσουμε το bug. Στην πραγματικότητα αυτό ήταν ένα απλό παράδειγμα του test-driven development, αλλά δεν έχει σημασία η σειρά που ακολουθείται για να γίνει η δουλειά.
\nΣτο πρώτο μας τεστ επικεντρωθήκαμε στην εσωτερική συμπεριφορά του κώδικα μας (στη μέθοδο του μοντέλου). Για αυτό το τεστ, θέλουμε να ελέγξουμε την συμπεριφορά του όπως θα τη βίωνε ο χρήστης μέσα από τον browser του.
\nΠροτού προσπαθήσουμε να φτιάξουμε το οτιδήποτε, ας ρίξουμε μια ματιά στα εργαλεία που έχουμε διαθέσιμα.
\nΤο Django παρέχει το τεστ Client για να εξομοιώνει τον χρήστη που αλληλεπιδρά με τον κώδικα σε επίπεδο view. Μπορούμε να το χρησιμοποιήσουμε στο αρχείο tests.py ή ακόμη και στο shell.
We will start again with the shell, where we need to do a couple of\nthings that won’t be necessary in tests.py. The first is to set up the test\nenvironment in the shell:
Linux / macOS
$ python manage.py shell\nWindows
...\\> py manage.py shell\n>>> from django.test.utils import setup_test_environment\n>>> setup_test_environment()\nΗ μέθοδος setup_test_environment() εγκαθιστά έναν template renderer ο οποίος μας επιτρέπει να ερευνήσουμε μερικά πρόσθετα attributes στα responses όπως το response.context το οποίο δεν θα ήταν διαθέσιμο αλλιώς. Σημειώστε ότι αυτή η μέθοδος δεν φτιάχνει καμία βάση δεδομένων για τεστ, κάτι το οποίο σημαίνει ότι θα τρέξει χρησιμοποιώντας την ήδη υπάρχουσα database. Επίσης σημειώστε ότι η έξοδος ίσως να είναι διαφορετική για εσάς ανάλογα τις ερωτήσεις που έχετε δημιουργήσει. Ίσως να λάβετε μη αναμενόμενα αποτελέσματα αν η ρύθμιση TIME_ZONE, μέσα στο γενικό αρχείο ρυθμίσεων settings.py, δεν είναι σωστή. Αν δεν την έχετε ρυθμίσει, κάντε το προτού προχωρήσετε.
Επόμενο βήμα είναι να κάνουμε import την τεστ κλάση για τον client (αργότερα στο αρχείο tests.py θα χρησιμοποιήσουμε την κλάση django.test.TestCase, η οποία έρχεται με δικό της client, οπότε αυτό δεν θα είναι απαραίτητο):
>>> from django.test import Client\n>>> # create an instance of the client for our use\n>>> client = Client()\nΜε αυτό έτοιμο, μπορούμε να βάλουμε τον client να εργαστεί για εμάς:
\n>>> # get a response from '/'\n>>> response = client.get('/')\nNot Found: /\n>>> # we should expect a 404 from that address; if you instead see an\n>>> # "Invalid HTTP_HOST header" error and a 400 response, you probably\n>>> # omitted the setup_test_environment() call described earlier.\n>>> response.status_code\n404\n>>> # on the other hand we should expect to find something at '/polls/'\n>>> # we'll use 'reverse()' rather than a hardcoded URL\n>>> from django.urls import reverse\n>>> response = client.get(reverse('polls:index'))\n>>> response.status_code\n200\n>>> response.content\nb'\\n <ul>\\n \\n <li><a href="/polls/1/">What's up?</a></li>\\n \\n </ul>\\n\\n'\n>>> response.context['latest_question_list']\n<QuerySet [<Question: What's up?>]>\nΗ λίστα με τις ψηφοφορίες εμφανίζει ψηφοφορίες οι οποίες δεν έχουν γίνει ακόμη published (δηλαδή αυτές που το pub_date έχει μελλοντική ημερομηνία). Ας το διορθώσουμε.
Στον Οδηγό 4 εισάγαμε την έννοια του class-based view, βασισμένο στη ListView:
class IndexView(generic.ListView):\n template_name = 'polls/index.html'\n context_object_name = 'latest_question_list'\n\n def get_queryset(self):\n """Return the last five published questions."""\n return Question.objects.order_by('-pub_date')[:5]\nΘα χρειαστεί να βελτιώσουμε τη μέθοδο get_queryset() και να την αλλάξουμε ούτως ώστε να ελέγχει και την ημερομηνία συγκρίνοντας τη με το timezone.now(). Πρώτα θα χρειαστεί να προσθέσουμε ένα import:
from django.utils import timezone\nκαι μετά πρέπει να βελτιώσουμε την μέθοδο get_queryset ως εξής:
def get_queryset(self):\n """\n Return the last five published questions (not including those set to be\n published in the future).\n """\n return Question.objects.filter(\n pub_date__lte=timezone.now()\n ).order_by('-pub_date')[:5]\nΗ μέθοδος Question.objects.filter(pub_date__lte=timezone.now()) επιστρέφει ένα queryset (συμπεριφέρεται ως μια Python λίστα) το οποίο περιέχει Questions των οποίων το pub_date είναι μικρότερο ή ίσο (επειδή στην προκειμένη επρόκειτο για ημερομηνίες, ίσως είναι καλύτερα να πούμε νωρίτερο ή ίσο) από το timezone.now (από το τώρα).
Now you can satisfy yourself that this behaves as expected by firing up\nrunserver, loading the site in your browser, creating Questions with\ndates in the past and future, and checking that only those that have been\npublished are listed. You don’t want to have to do that every single time you\nmake any change that might affect this - so let’s also create a test, based on\nour shell session above.
Προσθέστε τα ακόλουθα στο αρχείο polls/tests.py:
from django.urls import reverse\nΘα δημιουργήσουμε μια συνάρτηση συντόμευσης για να φτιάχνουμε ερωτήσεις και θα δημιουργήσουμε μια νέα test class:
\ndef create_question(question_text, days):\n """\n Create a question with the given `question_text` and published the\n given number of `days` offset to now (negative for questions published\n in the past, positive for questions that have yet to be published).\n """\n time = timezone.now() + datetime.timedelta(days=days)\n return Question.objects.create(question_text=question_text, pub_date=time)\n\n\nclass QuestionIndexViewTests(TestCase):\n def test_no_questions(self):\n """\n If no questions exist, an appropriate message is displayed.\n """\n response = self.client.get(reverse('polls:index'))\n self.assertEqual(response.status_code, 200)\n self.assertContains(response, "No polls are available.")\n self.assertQuerysetEqual(response.context['latest_question_list'], [])\n\n def test_past_question(self):\n """\n Questions with a pub_date in the past are displayed on the\n index page.\n """\n create_question(question_text="Past question.", days=-30)\n response = self.client.get(reverse('polls:index'))\n self.assertQuerysetEqual(\n response.context['latest_question_list'],\n ['<Question: Past question.>']\n )\n\n def test_future_question(self):\n """\n Questions with a pub_date in the future aren't displayed on\n the index page.\n """\n create_question(question_text="Future question.", days=30)\n response = self.client.get(reverse('polls:index'))\n self.assertContains(response, "No polls are available.")\n self.assertQuerysetEqual(response.context['latest_question_list'], [])\n\n def test_future_question_and_past_question(self):\n """\n Even if both past and future questions exist, only past questions\n are displayed.\n """\n create_question(question_text="Past question.", days=-30)\n create_question(question_text="Future question.", days=30)\n response = self.client.get(reverse('polls:index'))\n self.assertQuerysetEqual(\n response.context['latest_question_list'],\n ['<Question: Past question.>']\n )\n\n def test_two_past_questions(self):\n """\n The questions index page may display multiple questions.\n """\n create_question(question_text="Past question 1.", days=-30)\n create_question(question_text="Past question 2.", days=-5)\n response = self.client.get(reverse('polls:index'))\n self.assertQuerysetEqual(\n response.context['latest_question_list'],\n ['<Question: Past question 2.>', '<Question: Past question 1.>']\n )\nΑς κοιτάξουμε μερικά από τα παραπάνω τεστ πιο προσεκτικά.
\nΠρώτα, φτιάξαμε μια συνάρτηση (create_question) την οποία τη χρησιμοποιούμε ως συντόμευση για να δημιουργούμε ερωτήσεις.
test_no_questions doesn’t create any questions, but checks the message:\n«No polls are available.» and verifies the latest_question_list is empty.\nNote that the django.test.TestCase class provides some additional\nassertion methods. In these examples, we use\nassertContains() and\nassertQuerysetEqual().
In test_past_question, we create a question and verify that it appears in\nthe list.
In test_future_question, we create a question with a pub_date in the\nfuture. The database is reset for each test method, so the first question is no\nlonger there, and so again the index shouldn’t have any questions in it.
Και τα τεστ συνεχίζονται. Στην πραγματικότητα χρησιμοποιούμε τα τεστ για να εξομοιώσουμε τη συμπεριφορά του admin interface καθώς και των υπόλοιπων χρηστών που αλληλεπιδρούν με το site μέσω του browser. Κάθε φορά που αλλάζει το state του συστήματος μας (της εφαρμογής μας αν θέλετε) εξετάζουμε την έξοδο του συστήματος και αν αυτή ανταποκρίνεται στα αποτελέσματα που αναμένουμε.
\nDetailViewLink to this heading#Ότι έχουμε μέχρι τώρα λειτουργεί όπως θα θέλαμε να λειτουργεί. Ωστόσο, παρόλο που οι μελλοντικές ερωτήσεις δεν φαίνονται στην αρχική σελίδα της εφαρμογής μας (index), αν οι χρήστες μπορέσουν να μαντέψουν το σωστό URL που οδηγεί σε μια τέτοια ερώτηση (και δεν είναι κάτι δύσκολο αφού χρησιμοποιούμε IDs), τότε θα μπορέσουν να τη δουν. Άρα θα πρέπει να προσθέσουμε παρόμοιους περιορισμούς στο DetailView:
class DetailView(generic.DetailView):\n ...\n def get_queryset(self):\n """\n Excludes any questions that aren't published yet.\n """\n return Question.objects.filter(pub_date__lte=timezone.now())\nΚαι φυσικά θα χρειαστεί να προσθέσουμε μερικά τεστ για να ελέγξουμε ότι η ερώτηση (Question) της οποίας το pub_date είναι στο παρελθόν εμφανίζεται ενώ αυτής που είναι στο μέλλον όχι:
class QuestionDetailViewTests(TestCase):\n def test_future_question(self):\n """\n The detail view of a question with a pub_date in the future\n returns a 404 not found.\n """\n future_question = create_question(question_text='Future question.', days=5)\n url = reverse('polls:detail', args=(future_question.id,))\n response = self.client.get(url)\n self.assertEqual(response.status_code, 404)\n\n def test_past_question(self):\n """\n The detail view of a question with a pub_date in the past\n displays the question's text.\n """\n past_question = create_question(question_text='Past Question.', days=-5)\n url = reverse('polls:detail', args=(past_question.id,))\n response = self.client.get(url)\n self.assertContains(response, past_question.question_text)\nΧρωστάμε να προσθέσουμε μια παρόμοια μέθοδο get_queryset στο ResultsView και να δημιουργήσουμε μια νέα test class για αυτό το view. Θα είναι παρόμοια με αυτή που μόλις δημιουργήσαμε (DetailView). Στη πραγματικότητα θα είναι μια επανάληψη.
Θα μπορούσαμε επίσης να βελτιώσουμε την εφαρμογή μας και με άλλους τρόπους προσθέτοντας τεστ καθώς προχωράμε. Για παράδειγμα είναι λιγάκι ανόητο να μπορούν να γίνονται published οι ερωτήσεις (Questions) δίχως κάποιες απαντήσεις (Choices). Οπότε, τα views θα μπορούσα να ελέγξουν γι’ αυτό και να εξαιρέσουν (exclude) τέτοιες ερωτήσεις. Τα τεστ μας θα δημιουργούσαν μια ερώτηση χωρίς Choices και μετά θα έλεγχαν ότι αυτή η ερώτηση δεν θα γινόταν published. Ομοίως θα δημιουργούσαμε μια ερώτηση (σε άλλο τεστ) με Choices αυτή τη φορά και ελέγχαμε ότι αυτή η ερώτηση θα γινόταν published.
Ίσως οι logged-in admin χρήστες να επιτρεπόταν να δουν τις unpublished ερωτήσεις, αλλά όχι οι συνηθισμένοι επισκέπτες. Για ακόμη μια φορά: οτιδήποτε χρειάζεται να προστεθεί στο software για να επιτευχθεί ο στόχος σας θα πρέπει να συνοδεύεται από ένα τεστ, είτε γράψετε το test πρώτο και μετά τον κώδικα για να κάνετε το τεστ να επιτύχει είτε γράψετε τον κώδικα πρώτα και μετά το τεστ για να αποδείξετε ότι ο κώδικας σας λειτουργεί.
\nΘα φτάσετε σε ένα σημείο όπου θα κοιτάζετε τα τεστ σας και θα αναρωτιέστε αν ο κώδικας σας υποφέρει από υπερβολικό αριθμό τεστ, κάτι το οποίο μας φέρνει στο εξής:
\nΊσως να φαίνεται ότι τα τεστ αρχίζουν και γίνονται τεράστια καθώς και μη ελέγξιμα. Σύντομα θα διαπιστώσετε ότι υπάρχει περισσότερος κώδικας στα τεστ παρά στην εφαρμογή την ίδια και ότι η επανάληψη είναι αντιαισθητική εν συγκρίσει με την κομψή περιεκτικότητα του υπόλοιπου κώδικα σας.
\nΔεν πειράζει. Αφήστε το να μεγαλώσει. Τις πιο πολλές φορές θα γράψετε ένα τεστ και μετά θα το ξεχάσετε. Εκείνο όμως θα κάνει τη δουλειά του όσο εσείς συνεχίζετε με την ανάπτυξη της εφαρμογής σας (και γενικά όλου του project σας).
\nΜερικές φορές τα τεστ θα χρειαστεί να αναβαθμιστούν. Υποθέστε ότι βελτιώνουμε τα views ούτως ώστε μόνο οι ερωτήσεις (Questions) που έχουν απαντήσεις (Choices) θα γίνουν published. Σε αυτή την περίπτωση πολλά από τα τεστ μας θα αποτύχουν - λέγοντας μας ακριβώς ποια τεστ θα χρειαστεί να βελτιώσουμε για να είναι συμβατά με την εφαρμογή μας. Οπότε όσον αφορά την ανανέωση των τεστ, μην ανησυχείτε, τα τεστ φροντίζουν μόνα τους για τους εαυτούς τους.
Στη χειρότερη, καθώς αναπτύσσετε την εφαρμογή σας, ίσως βρεθείτε σε μια θέση όπου μερικά τεστ είναι πλέον περιττά. Και πάλι μην ανησυχείτε. Στον κόσμο του τεστ ο πλεονασμός (redundancy) είναι καλό στοιχείο.
\nΌσο τα τεστ σας είναι λογικά οργανωμένα δεν θα γίνουν αδιαχείριστα. Μερικοί κανόνες όσον αφορά τα τεστ είναι:
\nμια ξεχωριστή TestClass για κάθε μοντέλο ή view
μια ξεχωριστή μέθοδο τεστ για κάθε κατάσταση που θέλετε να τεστάρετε
να ονομάζετε τις μεθόδους τεστ όσο πιο περιεκτικά γίνεται σχετικά με αυτό που προσπαθούν να τεστάρουν
Αυτό ο οδηγός έκανε μια εισαγωγή στον κόσμο των τεστ. Υπάρχουν πολλά περισσότερα που μπορείτε να κάνετε όπως επίσης και περισσότερα εργαλεία που μπορείτε να χρησιμοποιήσετε για να φτιάξετε πολύ έξυπνα τεστ.
\nΓια παράδειγμα, παρόλο που τα τεστ σε αυτό τον οδηγό κάλυψαν ένα κομμάτι από την εσωτερική λειτουργία του κώδικα μας (μέθοδος μοντέλου) και άλλο ένα από τον τρόπο που τα views κάνουν publish τις ερωτήσεις μας, μπορείτε να χρησιμοποιήσετε ένα «in-browser» framework όπως το Selenium για να τεστάρετε τον τρόπο με τον οποίο η HTML γίνεται render στον browser. Αυτά τα εργαλεία δεν σας επιτρέπουν να ελέγξετε μόνο τη συμπεριφορά του Django κώδικα σας αλλά και του κώδικα π.χ της Javascript (που πολύ πιθανόν να έχετε). Είναι αρκετά συναρπαστικό να μπορείτε να βλέπετε τα τεστ σας να ανοίγουν τον browser σας και να αλληλεπιδρούν με το site ακριβώς όπως ένας άνθρωπος θα το έκανε! Το Django περιλαμβάνει την κλάση LiveServerTestCase για να διευκολύνει την ενσωμάτωση (συνεργασία) με εργαλεία όπως το Selenium.
Αν έχετε μια περίπλοκη εφαρμογή ίσως να θέλετε να τρέχουν τα τεστ, αυτόματα, κάθε φορά που κάνετε commit για λόγους του continuous integration, ούτως ώστε το ίδιο το quality control (έλεγχος ποιότητας) - να είναι τουλάχιστον μερικώς - αυτοματοποιημένο.
\nΈνας καλός τρόπος για να εντοπίσετε τα μέρη της εφαρμογής σας που δεν έχουν γραφτεί τεστ για αυτά, είναι να ελέγξετε το κατά πόσο είναι καλυμμένος ο κώδικας σας με τεστ. Αυτό επίσης σας βοηθά στο να αναγνωρίσετε αδύναμο ή ακόμη και αχρησιμοποίητο-νεκρό κώδικα. Αν δεν μπορείτε να τεστάρετε ένα κομμάτι κώδικα, τότε αυτό ίσως σημαίνει ότι ο κώδικας θα πρέπει να ξαναγραφτεί ή να αφαιρεθεί τελείως. Το Coverage θα σας βοηθήσει (και είναι πολύ σημαντικό αυτό) να αναγνωρίσετε τον νεκρό κώδικα. Δείτε στην αναφορά Δουλεύοντας με το coverage.py για περισσότερες λεπτομέρειες.
\nΕπίσης το άρθρο Testing με το Django περιέχει περισσότερες πληροφορίες σχετικά με το testing.
\nΓια περισσότερες πληροφορίες σχετικά με τα τεστ δείτε στο άρθρο Testing με το Django.
\nΌταν είστε εξοικειωμένοι με το concept και τη λειτουργία των τεστ στο Django, διαβάστε το έκτο μέρος αυτού του οδηγού για να μάθετε περισσότερα σχετικά με τη διαχείριση των στατικών αρχείων (static files).
\n