Η πυραμίδα δοκιμής front-end: Πώς να ξανασκεφτείτε τις δοκιμές σας

Εάν δοκιμάζετε εφαρμογές διεπαφής, θα πρέπει να γνωρίζετε για τη δοκιμαστική πυραμίδα διεπαφής .

Σε αυτό το άρθρο θα δούμε τι είναι η πυραμίδα δοκιμής front-end και πώς να τη χρησιμοποιήσετε για να δημιουργήσετε ολοκληρωμένες σουίτες δοκιμών.

Η πυραμίδα δοκιμής εμπρός

Η δοκιμαστική πυραμίδα front-end είναι μια αναπαράσταση του τρόπου με τον οποίο πρέπει να δομηθεί μια δοκιμαστική σουίτα.

Η ιδανική δοκιμαστική σουίτα αποτελείται από δοκιμές μονάδας, μερικές δοκιμές στιγμιότυπου και μερικές δοκιμές από άκρο σε άκρο (e2e).

Αυτή είναι μια ανανεωμένη έκδοση της δοκιμαστικής πυραμίδας, που είναι συγκεκριμένη για τη δοκιμή εφαρμογών front-end.

Σε αυτό το άρθρο θα εξετάσουμε πώς μοιάζει κάθε ένας από αυτούς τους τύπους δοκιμών. Για να το κάνουμε αυτό, θα δημιουργήσουμε μια δοκιμαστική σουίτα για ένα παράδειγμα εφαρμογής.

Η εφαρμογή

Για να μάθετε λεπτομερώς για την πυραμίδα δοκιμής front-end, θα εξετάσουμε πώς να δοκιμάσουμε μια εφαρμογή ιστού.

Η εφαρμογή είναι μια απλή τροπική εφαρμογή. Κάνοντας κλικ σε ένα κουμπί ανοίγει ένα modal και κάνοντας κλικ σε ένα κουμπί OK στο modal κλείνει το modal.

Θα δημιουργήσουμε την εφαρμογή από ένα πλαίσιο βασισμένο σε στοιχεία. Μην ανησυχείτε για τις λεπτομέρειες - θα διατηρήσουμε αυτό το υψηλό επίπεδο.

Η εφαρμογή αποτελείται από τρία συστατικά - ένα Buttonσυστατικό, ένα Modalσυστατικό και ένα Appσυστατικό.

Οι πρώτες δοκιμές που θα γράψουμε είναι δοκιμές μονάδας. Στην πυραμίδα δοκιμής front-end, το μεγαλύτερο μέρος των δοκιμών μας είναι δοκιμές μονάδας.

Δοκιμές μονάδας

Η μονάδα δοκιμάζει μονάδες δοκιμής μιας βάσης κώδικα.

Καλούν συναρτήσεις - ή μονάδες - άμεσα και βεβαιωθείτε ότι επιστρέφουν το σωστό αποτέλεσμα.

Στην εφαρμογή μας, τα συστατικά μας είναι μονάδες. Έτσι θα γράψουμε τεστ μονάδας για Button and Modal. Δεν χρειάζεται να γράφετε δοκιμές για το Appσυστατικό μας , επειδή δεν υπάρχει λογική σε αυτό.

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

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

Στις δοκιμές μας θα ενεργοποιήσουμε ενέργειες στα στοιχεία και θα ελέγξουμε ότι τα στοιχεία συμπεριφέρονται όπως αναμενόταν.

Δεν θα δούμε τον κώδικα. Αλλά οι προδιαγραφές για τα εξαρτήματά μας μοιάζουν με αυτήν:

  • Το Modal έχει κλάση είναι ενεργό όταν το displayModal είναι αληθινό
  • Το Modal δεν έχει κλάση είναι ενεργό όταν το displayModal είναι ψευδές
  • Modal κλήσεις toggleModal όταν πατάτε το κουμπί επιτυχίας
  • Modal κλήσεις toggleModal όταν κάνετε κλικ στο κουμπί διαγραφής
  • Το κουμπί καλεί toggleModal όταν κάνετε κλικ στο κουμπί

Οι δοκιμές μας θα καταστήσουν ρηχά τα συστατικά και έπειτα θα ελέγξουν κάθε μια από τις προδιαγραφές λειτουργεί.

Υπάρχουν μερικοί λόγοι για τους οποίους οι δοκιμές μονάδας πρέπει να αποτελούν το μεγαλύτερο μέρος της σουίτας δοκιμών μας:

Οι δοκιμές μονάδας είναι γρήγορες.

Μια σειρά από εκατοντάδες τεστ μονάδας εκτελείται σε λίγα δευτερόλεπτα.

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

Οι δοκιμές μονάδας είναι κοκκώδεις

Με άλλα λόγια, είναι πολύ συγκεκριμένα.

Εάν μια δοκιμή μονάδας αποτυγχάνει, η δοκιμασμένη δοκιμή θα μας πει πώς και γιατί αποτυγχάνει.

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

Αλλά δεν μπορούν να δοκιμάσουν τα πάντα.

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

Δοκιμές στιγμιότυπου

Οι δοκιμές στιγμιότυπου είναι δοκιμές που τραβούν μια φωτογραφία του συστατικού που αποδίδετε και τη συγκρίνουν με μια προηγούμενη εικόνα του στοιχείου σας.

Ο καλύτερος τρόπος για να γράψετε δοκιμές στιγμιότυπου σε JavaScript είναι με το Jest.

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

Για να εγγραφείτε μια δοκιμή στιγμιότυπου στο Jest, πρέπει να προσθέσετε κάτι σαν τον παρακάτω κώδικα:

const renderedMarkup = renderToString(ModalComponent)expect(renderedMarkup).toMatchSnapshot()

Μόλις εγγραφείτε ένα στιγμιότυπο, ο Jest φροντίζει τα πάντα. Κάθε φορά που εκτελούνται οι δοκιμές μονάδας δημιουργεί ένα στιγμιότυπο και συγκρίνεται με το προηγούμενο στιγμιότυπο.

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

Στην παρακάτω δοκιμή, κάποιος έχει διαγράψει την modal-card-footτάξη από το er>.

Snapshot tests are a way of checking nothing has changed about the style or markup of a component.

If the snapshot tests pass, we know our code change didn’t affect the display of our components.

If the tests fail, then we know that we did affect the render of the components and can check manually that the style is still correct.

You should have at least 1 snapshot test per component. A typical snapshot test renders the component with some state to check it renders correctly.

Now we have unit tests and snapshot tests, it’s time to look at end to end (e2e) tests.

End to end tests

End to end (e2e) tests are high-level tests.

They perform the same actions as we would if we tested an App manually.

In our app we have a user journey. When the user clicks on the button the modal will open, when they click the button in the modal the modal closes.

We can write an end to end test that runs through this journey. The test will open the browser, navigate to the webpage, and run through each action to make sure the app is behaving correctly.

These tests tell us that our units are working together correctly. It gives us high confidence that the main functionality of the app is working.

There are a few ways to write end to end tests for JavaScript applications. There are programs like test cafe that record you performing actions in a browser and replay them as tests.

There are also projects like nightwatch that let you write the tests in JavaScript. I would recommend using a library like nightwatch. It’s easy to pick up, and the tests run faster than recorded tests.

That said, nightwatch tests are still relatively slow. A suite of 200 unit tests takes seconds to run, a suite of 200 end to end tests takes minutes to run.

The other problem with end to end tests is that they are difficult to debug. When a test fails, it’s hard to find out why it failed, because the tests cover a lot of functionality.

Conclusion

To test front-end component based web apps effectively, you need to three types of tests. Unit tests, snapshot tests, and e2e tests.

You should have multiple unit tests for each component, one or two snapshot tests per component, and one or two end to end tests that test multiple components connected together.

Overall unit test will make up the bulk of your tests, you’ll have some snapshot tests, and a few e2e tests.

If you follow the front-end testing pyramid, you’ll create maintainable web apps with killer test suites.

You can see an example repository of the app with snapshot tests, unit tests, and end to end tests on GitHub.