Sollte man immer eine Testabdeckung von 100% anstreben?

Falls ja, wie testet man private Methoden?
Kann man/Wie Methoden Methoden ohne Rückgabewert testeten?

Beim Testen würde ich immer drauf achten, was sinnvoll ist, und dann aus reiner Paranoia noch ein bißchen mehr machen. Das schwierigste ist natürlich herauszufinden, was für deine Klasse / Anwendung sinnvoll ist und wieviel Aufwand du zum Testen treiben willst, also bildhaft der Unterschied zwischen Textausgabe und der zentralen, kritischen Flughafensteuerung.

Grundsätzlich unterscheidet man zwischen verschiedenen Abdeckungscharakteristiken. Wikipedia liefert da ganz gute Basisinformationen, ansonsten empfehle ich nach Fachliteratur und Vorlesungsfolien zum Thema zu suchen.

Zu der Frage, was sinnvoll ist, würde ich natürlich beim Zweck der Klasse starten - also was soll sie tun und welche Sonderfälle gibt es. Die 100%-Zeilenabdeckung (C0-Test) sollten sich durch reine Variation der Parameter und des Objektzustands erreichen lassen, ansonsten hast du quasi toten Code. Wenn du das im Kopf durchgehst, ergeben sich dadurch schon eine Menge Testszenarien. Gerade auf die Grenzwerte, also ab wann würde ich eine Änderung im Verhalten erwarten, würde ich mich konzentrieren. Ebenfalls nicht zu unterschätzen sind Negativtests. Wie verhält sich die Software bei gezielt falschen Eingaben und wann werden Exceptions geworfen bzw. gefangen?

Zu der private-Problematik: Überprüf doch mal, ob du die Methoden nicht auch als static deklarieren kannst. Spricht für gutes Design und erlaubt einfaches Testen. :-)

100% Testabdeckung ist Dummgeschwätz aus Marketing, Vertrieb und Management.

Definition: Testabdeckung ist das Verhältnis von gemachten Tests zu theoretisch möglichen Tests
Wiki Testabdeckung

Selbst bei einfachsten Applikationen würden die Testzeiten ins Unermessliche gehen.
Wenn eine Applikation/Methode beispielsweise 100 verschiedene binäre Zustände hätte, so müßte also 2¹⁰⁰ Tests gefahren werden.
Angenommen man könnte pro Sekunde 1000000 Tests durchführen, dann braucht der Test 40200 Milliarden Jahre. Zur Erinnerung, das Alter des Universums wird auch 15 Milliarden Jahre geschätzt.

Eine Methode die 3 32 Bitwerte annimmt, kann auf 2⁹⁶ verschiedene Arten aufgerufen werden.
Bei einer Methode mit einem String der IMMER genau 6 Zeichen lang ist, ergeben sich ebenfalls 2⁹⁶ verschiedene Aufrufe.

Selbst bei einfachsten Anwendungen tendiert die Testabdeckung IMMER gegen 0

Seit ich diese Frage gelesen habe, gehen mir das Thema und die daraus folgenden Probleme nicht mehr aus dem Sinn ;-)

100% Codeabdeckung durch Tests finde ich gut und richtig, wie aber bekomme ich das z.B. hier hin?

import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.ParserConfigurationException;
import org.w3c.dom.Document;

try {
  final Document doc = DocumentBuilderFactory.newInstance().
    newDocumentBuilder().newDocument();
} catch (ParserConfigurationException e) {
  // egal, was auch immer ...
  e.printStackTrace();
}

Sicher doch nicht, indem ich die Verantwortung abwälze und die Exception einfach werfe (um dieser Antwort schon mal vorzugreifen)?

Nachtrag zur Verdeutlichung:

InputStream stream = new ByteArrayInputStream("foo".getBytes());
try {
  stream.read();
} catch (IOException e){
  ; // hier komme ich nie hin
}

stream.read() wirft eine IOException, da ich versuche, sauber zu designen und gegen Interfaces zu programmieren, statt gegen Implementierungen. Die read()-Implementierung von ByteArrayInputStream wirft aber gar keine IOException (und warum sollte sie auch). Ich habe hier also toten Code, weil ich mich an gute und sinnvolle Grundsätze der Softwareentwicklung halte - und ich kann nicht 100% Testabdeckung erreichen, weil ich den code im catch-Block nicht testen kann.

Es ist aber auch kein Problem eine private Methode zu testen:

Folgende Methode soll getestet werden:

public class Controller {
    private Date buildStartTime(final int intVal, final long longVal, final int intVal) {
    ...
    }
}

JUnitTest:

Controller instance = new Controller();
    Date result = null;
    try {
        Class clazz = Controller.class;
        Method method = clazz.getDeclaredMethod("buildStartTime", new Class[]{Integer.TYPE, Long.TYPE, Integer.TYPE });
        method.setAccessible(true);
        result = (Date) method.invoke(instance, new Object[]{ 180, 60000L, 40});
     } catch (Exception e) {
        e.printStackTrace();
        fail();
     }

Anweisungsüberdeckung ist glaube ich ein angemessener Kompromiss. Wenn man mehr Arbeit reinstecken möchte, strebt man Bedingungüberdeckung an. Zusätzlich sollte man Grenzwerttests für die one-off-Problematik erstellen.

Prinzipell gilt auch beim testen ein ganz einfaches Prinzip:
So wenig wie möglich, soviel wie nötig!

Es ist sinnlos Klassen tot zu testen. (Tottestsn = 100%)
Wichtig ist, dass 80% der Klasse abgedeckt sind.
80/20 Prinzip (Paretoprinzip)

Du wirst sonst mit dem Testen vermutlich nicht mehr fertig werden.
Teste deine Programme so, wie sie in der praxis auch angewendet werden, aber schreibe keine sinnlosen Tests, den auch deren Ergebnisse werden dich zu keinem Ergebnis bringen.

Ps: Nur so als Anhang, wenn man Test-driven Development betreibt, hast du z.b. ja auch "nur" die Praxisfälle abgedeckt...