Was zum Unit-Test, in Android-Apps

Question

Meine Apps sind meist GUIs, die für einen Großteil ihrer Informationen an einen Server kommunizieren. Wenn irgendetwas schief geht, wird es normalerweise im Netzwerkaufruf sein oder falsche Annahmen über ein JSON-Objekt machen.

Komponententests sind nicht gut für diese netzwerkbezogenen und E/A-bezogenen Aufgaben, andernfalls werden sie nicht als Komponententests bezeichnet.

SO versuche ich den Punkt der Unit Tests in meinem Fall zu sammeln. Warum würde ich testen, ob ein Android-Button klicken kann oder ein EditText sehen kann, was ich tippe? Ich verstehe einfach nicht das Dienstprogramm diese mühsame Tests von implementating

private void initElements(){ 
    placeButton = (Button) findViewById(R.id.currplace); 
    placeButton.setText(MainActivity.this.getString(R.string.findingLocation)); 
    placeButton.setEnabled(false); 
    selectplaceLayout = (LinearLayout)findViewById(R.id.selectplaceLayout); 
    selectplaceLayout.setVisibility(View.GONE); 
    splash = (RelativeLayout)findViewById(R.id.splashbg); 
    infoLayout = (LinearLayout)findViewById(R.id.infoLayout); 
} 

wenn diese über Methode übergeben, die alle meine Aktivitäten in onCreate laufen, dann weiß ich, die App funktioniert. Ein Komponententest wäre eine redundante zeitaufwendige Sache zu erstellen. Zeitaufwendig, weil ich nicht mit allen Methoden im jUnit- und Android-Testframework vertraut bin.

also, lange Geschichte kurz, was ist der Punkt? Gibt es eine besondere Art, über diese Tests nachzudenken? Alle Beispiele und Tutorials, die ich bisher gesehen habe, sprechen nur der Einfachheit halber über die einfachsten Beispiele, aber ich kann mir keine praktischen Anwendungen für Komponententests in einer Client-Server-App vorstellen.

Was soll ich herausfinden, indem ich auf die Android-Ansichten zugreife, von denen ich bereits weiß, dass ich sie deklariert und initialisiert habe? Ich muss in einer zu beschränkten Art und Weise darüber denken

so, Einsicht geschätzt

Answer 1

Es gibt viele Facetten in Frage, aber meiner Meinung nach - Sie wahrscheinlich nicht Komponententests in Ihr Projekt benötigen.

Komponententests leuchten wirklich, wenn Sie viel Geschäftslogik zu Ihrem Projekt benötigen. In diesem Fall möchten Sie Ihre Anwendung wahrscheinlich in mehrere Ebenen (z. B. 3-Tier-Architektur) aufteilen, um unter anderem einige natürliche Isolierungen für Business-Logic-Layer hinzuzufügen und diese mit einem Sicherheitsnetz von Komponententests abzudecken.

Dieses Sicherheitsnetz deckt Ihren Arsch während Refactor der Business-Schicht, und das ist eine der wichtigsten Dinge, die Sie aus Komponententests (TDD kann einige nette zusätzliche Nebenwirkungen bieten, obwohl).

Es ist jedoch nicht alles Einhörner und Regenbogen und Unit-Test kann kosten, und manchmal kosten sie viel. Gute Komponententests sind isoliert (d. H. Befassen sich mit kleinen Codestücken). Das bedeutet, dass Sie Abstraktionsschichten hinzufügen müssen, um Ihre Klassen unter Beweis zu stellen.

Dies kann sich positiv auf Ihr System oder negativ auswirken. Layering macht Ihr System flexibler mit Kosten für erhöhte Komplexität.

Mit diesem gesagt - ist der Wert der Unit-Tests proportional zu der Menge an abstrakten Business-Logik, die Sie in Ihrem Projekt einführen werden. Sie können sich das auch so vorstellen - wenn es zu kompliziert ist, abstrakte Schichten zu Ihrer Architektur hinzuzufügen - fügen Sie keine Komponententests hinzu - sie werden die Dinge nur komplizierter machen (Architektur und Aufbau weise).

Basierend auf Ihrer Beschreibung - Ihre typische App neigen dazu, ziemlich viel Präsentationsschicht für einige externe Server-Seite sein. Es ist nicht so viel, außer Informationen auf Android-Handy präsentieren und Benutzeraktionen in Befehle zu Server-Seite, wo Hauptgeschäftslogik getan wird (Steuern) verwandelt.

Bei diesem Ansatz bezieht sich der meiste Code, den Sie wahrscheinlich schreiben, auf "wie man dies und das anzeigt" oder "wie man Server in diesem und jenem Fall signalisiert". Diese Art von Code ist offensichtlich stark abhängig von der Plattform und das bedeutet, dass, wenn Sie es unter Test stellen wollen, Sie viel und viele Android spezifischen Code \ Verhalten verspotten müssen.

Jetzt ist Android etwas spezifische Plattform. Es wurde entwickelt, um sowohl leistungsoptimiert zu sein als auch Entwicklern zu ermöglichen, Apps schnell zu starten und zu produzieren. Oft bedeutet dies eine gewisse Anzahl von "swiss-knife" -Klassen, die Sie verwenden, erweitern und im Allgemeinen das beschleunigt das Schreiben von Code, aber das Spotten dieser Klassen kann eine echte Hölle werden. Ganz zu schweigen davon, dass Sie Verständnis dafür haben müssen, wie Plattform unter der Haube funktioniert, um diese als nützlich zu machen. Mit anderen Worten, der Aufwand für diese Tests wird hoch sein.

Eine andere Sache, die beim Testen von Präsentationsebenen falsch ist, besteht darin, dass sie sich viel dynamischer ändern als Business-Schichten. Und das bedeutet natürlich, dass Sie die Tests umgestalten müssen, was noch mehr Aufwand bedeutet.

Ich muss jedoch eine Sache über verschiedene Hilfs-/Hilfsklassen sagen. Auch wenn diese Klassen zur Präsentationsschicht gehören und Android-Code abhängen, aber einige nicht-triviale Logik machen und ist es einfach, Unit-Tests für sie zu verspotten und zu schreiben, könnte es tatsächlich eine gute Idee sein, dies zu tun. Wenn Sie jedoch viel Code haben, könnte dies ein Signal dafür sein, dass Sie Ihre Architektur/Schichtung nicht gut entworfen haben und neu überdenken müssen, was Sie tun.

Am Ende Ihre Frage beantworten Sie diese Fragen zuerst beantworten müssen:

Wird es überzudimensionieren wird abstrakte Schicht hinzuzufügen, die von der Plattform zu Ihrer Anwendung getrennt ist (scheint, wie in Ihrem Fall es wird) ? Wenn ja - nicht Unit-Tests verwenden - sie werden nur verlangsamen. Wenn nein - benutze sie.

Werden Sie viel umgestalten? Wenn das ein großes Projekt mit viel Code und somit Wartung ist, wirst du wahrscheinlich auch in Layering und Unit-Tests investieren (aber auf einen Blick scheint das nicht dein Fall zu sein). Wenn das nicht Ihr Fall ist - kümmern Sie sich nicht um Komponententests und gehen Sie schnell.

Müssen Sie viel Playmate machen, um Ihre Komponententests zu schreiben? Wenn ja (scheint Ihr Fall zu sein) - schreiben Sie keine Unit Tests - sie sind es nicht wert.

Hoffe, das wird helfen.