Beiträge von braindead

Hey,

all das was du aufzählst sind genau die Gründe warum man Tests schreibt. Wenn ein Projekt genügend komplex ist, dann sind Tests unerlässlich. Natürlich ist es für den Entwickler erstmal nervig Tests zu entwickeln, aber gerade wenn im Team entwickelt wird und man nicht jede Komponente der Software genau kennt, dann weiß man im Zweifel nicht ob die Änderung irgendwas kaputt macht das nicht sofort auffällt.

Die Zeit die zum Entwickeln der Tests draufgeht ist mehr als gut angelegt. Stell dir einfach mal vor die lieferst eine Software zum Kunden aus und alles funktioniert wie es soll. Nach einem Jahr kommt der Kunde und möchte etwas geändert haben. Das implementierst du und lieferst es wieder aus. Und plötzlich passieren an einer anderen Stelle Fehler. Z.B. werden Termine nicht mehr richtig gebucht oÄ. Und der Kunde verliert, auf Grund deines Fehlers, hunderttausende oder sogar millionen von Euro. Der kommt 1. nicht wieder und 2. wird er dich wohl auf Schadensersatz verklagen.

Das ist natürlich ein drastisches Beispiel. Aber es reicht ja auch schon wenn durch fehlende Tests ein Entwickler eine Woche auf die Suche nach einem Bug geht. Das kostet dann halt auch mal 4000€. Wenn sowas bei jedem Release vorkommt dann macht dein Chef sich auch mal Gedanken was du da so treibst

Am besten hat man gute Tests und ein Build-Script das vorher sämtliche Tests abarbeitet und bei Fehlern den Dienst verweigert. So minimiert man Fehler drastisch.

Zitat von Lucas de Vil

Moin,
Bei Android bin ich offenbar nicht einmal fähig einen einzigen Unit Test für ein einziges Modell anzulegen. Das Internet ist voll von Tutorials, mit denen ich meine Activity getestet bekomme – was mir allerdings erst mal völlig wurscht ist, weil die alles Andere als fertig ist.

Hallo,

nur als Tipp: Man schreibt Test eigentlich bevor man anfängt etwas zu implementieren. Nicht wenn es schon implementiert ist.

Car car = new Car();
car.drive(10);


assertEquals(10, car.getDrivenDistance());

und dann überlegst du dir wie du drive implementieren musst damit es genau das macht. Und zwar nur das

Hey das komplette Model lädst du niemals komplett in den Speicher, das wäre vollkommen falsch. Für die von dir genannten Anwendungsfälle gibt es die ContentProvider die den Zugriff auf die Datenbank regeln. Von der Application Klasse sollte man idR. die Finger lassen. Und der maximale Payload für einen Intent sind auch irgendwas um 1mb...

Schau dir diesen Artikel mal an: http://www.vogella.com/tutorials/AndroidSQLite/article.html

ContentProvider sind im Prinzip eine Abstraktionsschicht der Datenbank. Du sagst was du haben willst, z.B. eine Liste aller Angestellten und der ContentProvider liefert dir einen Cursor zurück über den du dann iterieren kannst. Genauso kannst du über ContentProvider Datensätze erstellen/bearbeiten.

Außerdem bietet Android schon fertige CursorAdapter um die Daten des Cursors z.B. einer ListView darzustellen.

@Override
    public Loader<Cursor> onCreateLoader(int id, Bundle bundle) {
        CursorLoader cursorLoader = null;


        switch (id) {
            case LOADER_LIST:
                cursorLoader = new CursorLoader(this, TaskProvider.CONTENT_URI, null, null, null, null);
                break;
        }


        return cursorLoader;
    }


    @Override
    public void onLoadFinished(Loader<Cursor> cursorLoader, Cursor cursor) {
        switch(cursorLoader.getId()) {
            case LOADER_LIST:
                mListView.setAdapter(new SimpleCursorAdapter(this, android.R.layout.simple_list_item_1, cursor, new String[]{Task.NAME}, new int[]{android.R.id.text1}, 0));
                break;
        }
    }