Πώς να δοκιμάσετε τη χρήση ψεύτικων δεδομένων στο iOS

Προκειμένου να παρέχεται λογισμικό υψηλής ποιότητας και να αποφεύγεται η παλινδρόμηση, η δοκιμή μονάδας υλοποίησης είναι απαραίτητη για κάθε εφαρμογή iOS.
Τα κοροϊδευτικά αντικείμενα είναι μια τεχνική στη δοκιμή μονάδων που δημιουργεί ψεύτικα αντικείμενα χρησιμοποιώντας τα ίδια API με τα πραγματικά.
Αυτό το άρθρο είναι wirtten να σας παρέχει τις βέλτιστες πρακτικές σχετικά με τον τρόπο χρήσης ψευδών δεδομένων και τη δοκιμή μονάδων εγγραφής για τα πιο εμφανιζόμενα σενάρια σε εφαρμογές iOS.

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

Τα παρακάτω μέρη θα συζητήσουν πώς μπορείτε να γράψετε δοκιμές χρησιμοποιώντας πλαστά δεδομένα για κοινά χρησιμοποιούμενα API iOS.

Προεπιλογές χρήστη

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

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

Ως εκ τούτου, θα προσπαθήσουμε να προσφέρουμε μια πρακτική λύση για τη δοκιμή του UserDefaultsrather παρά να αφαιρέσουμε το API του με πρωτόκολλα.

Μπορούμε να δημιουργήσουμε δύο νέες λειτουργίες στα UserDefaults

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

Σε αυτήν την περίπτωση, προετοιμάζουμε ένα νέο αντικείμενο των UserDefaults με το όνομαName - testDefaults ότι είναι απόλυτα ανεξάρτητο από τα standard UserDefaults.

Ας προσπαθήσουμε να γράψουμε μια απλή δοκιμή που χρησιμοποιεί τα UserDefaults

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

Το καλύτερο μέρος για τον καθαρισμό αυτών των δεδομένων θα είναι, φυσικά, η λειτουργία tearDown στην τάξη δοκιμών μονάδων μας.

Singelton Αντικείμενα

Τα Singletons Objects χρησιμοποιούνται σε iOS σε πολλά API, τα βρίσκουμε στο NSFileManager, NSApplication, UIApplication και σε πολλά άλλα μέρη.

Το να γνωρίζετε πώς να δοκιμάσετε τα singletons είναι ένα χρήσιμο πράγμα που πρέπει να γνωρίζετε για τους προγραμματιστές του iOS.

Στο παράδειγμά μας, θα χρησιμοποιήσουμε το iad framework του μήλου. Θα δημιουργήσουμε ένα αρχείο για να λάβουμε μια τοπική ανταπόκριση JSON αντί για πραγματικά δεδομένα σχετικά με λεπτομέρειες σχετικά με τη διαφήμιση.

Ένα ωραίο χαρακτηριστικό στο iOS είναι ότι οι επεκτάσεις στο swift μας επιτρέπουν όχι μόνο να προσθέτουμε νέες λειτουργίες για ένα προκαθορισμένο API αλλά και να τις προσαρμόζουμε στα προσαρμοσμένα πρωτόκολλά μας.

Ας ορίσουμε ένα πρωτόκολλο AdvertismentClient

Μετά από αυτό, συμμορφωνόμαστε με αυτό το πρωτόκολλο και από το προεπιλεγμένο ADClient και από τον ψεύτικο διαφημιστικό πελάτη που ακολουθούμε

Τότε μεταβάλλουμε την εξάρτηση είτε σε

ιδιωτικό var adClient: AdvertismentClient = ADClient.shared ()

ή

ιδιωτικό var adClient: AdvertismentClient = MockAdClient ()

και να το χρησιμοποιήσετε ως εξής

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

Βασικά δεδομένα

Τα βασικά δεδομένα εξακολουθούν να χρησιμοποιούνται σε μεγάλο βαθμό στο iOS για την προσωρινή αποθήκευση δεδομένων. Ο έλεγχος των οντοτήτων στοιχείων πυρήνα μπορεί να είναι δύσκολο. Παρακάτω θα εξηγήσουμε μια καλή πρακτική τόσο της οργάνωσης των βασικών υπηρεσιών δεδομένων όσο και των δεδομένων που δημιουργούν δεδομένα.

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

Αυτό έχει δύο πλεονεκτήματα:

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

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

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

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

Όταν εξετάζουμε τη Μονάδα πάντα θα πρέπει να αποφεύγουμε να αλλάζουμε την κατάσταση των πραγματικών αντικειμένων όταν τα δοκιμάζουμε.

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

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

Και στη δοκιμαστική μας τάξη, μπορούμε να την αρχικοποιήσουμε με την ψεύτικη στοίβα δεδομένων

Μπορούμε τώρα να γράψουμε μερικές απλές δοκιμές ως εξής:

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

Αιτήματα δικτύου

Όταν δοκιμάζουμε το Layer Network μπορούμε να χρησιμοποιήσουμε την προσέγγιση με πρωτόκολλο προσανατολισμού για να δημιουργήσουμε ένα πρωτόκολλο και να το συμμορφωθούμε τόσο από την πραγματική NetworkService και από το MockNetworkService και στη συνέχεια να εγχύσουμε εξαρτήσεις χρησιμοποιώντας είτε πραγματική είτε κοροϊδευμένη υπηρεσία.

Σε αυτό το άρθρο αν και θα χρησιμοποιήσουμε μια πραγματικά ωραία βιβλιοθήκη ανοιχτού κώδικα που ονομάζεται OHHTTPStubs που θα χειριστεί το κοροϊδάρισμα και το stubbing ακόμα καλύτερα.

Το καλό για αυτή τη βιβλιοθήκη είναι ότι λειτουργεί πολύ καλά με τη διάσημη βιβλιοθήκη δικτύωσης iOS Alamofire.

Το αίτημα Stubbing Network είναι πραγματικά εύκολο με το OHHTTPStubs μπορείτε να αντικαταστήσετε οποιαδήποτε απόκριση για μια συγκεκριμένη διαδρομή ή έναν κεντρικό υπολογιστή δίνοντας μια προσαρμοσμένη απάντηση με ένα λεξικό.

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

αφήστε tasksURL = URL (συμβολοσειρά: "https://jsonplaceholder.typicode.com/todos")!

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

Η χειροκίνητη δημιουργία του λεξικού για απόκριση είναι ένα μεγάλο χαρακτηριστικό, αλλά όταν θέλουμε να επιστρέψουμε ένα μεγάλο JSON δεδομένα με πολλές ιδιότητες μπορεί να γίνει ακατάστατο και δύσκολα συντηρητικό στις δοκιμαστικές μας τάξεις.

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

Τώρα κάθε φορά που η εφαρμογή μας στέλνει το αίτημα, θα λάβουμε την απάντηση από το αρχείο myResponse.json που αποθηκεύσαμε στα αρχεία μας.

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

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

Συμπερασματικά

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

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

Συζητήσαμε πώς να δοκιμάζουμε τα UserDefaults, Singeltons, Core Data και Requests Network.

Εάν σας άρεσε αυτό το άρθρο, βεβαιωθείτε ότι έχετε χτυπήσει για να δείξετε την υποστήριξή σας.

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

Εάν έχετε οποιεσδήποτε ερωτήσεις ή σχόλια, μπορείτε να αφήσετε ένα σημείωμα εδώ ή να μου στείλετε email στο arlindaliu.dev@gmail.com.