Sebbene JMockit ti permetta di risolvere molti problemi, ci sono due cose da considerare: non funzionerà per tutte le lingue là fuori e potrebbe essere semplicemente il soluzione sbagliata.
JMockit si basa su una serie di tecniche che funzionano, ma che non sono indipendenti dalla lingua. Mentre ogni linguaggio orientato agli oggetti là fuori ti permetterà di passare una classe in un metodo e di chiamare un metodo su quella classe (dipendenza da iniezione), non tutte le lingue ti permetteranno di deridere o fingere ogni chiamata fatta. "Lavorare efficacemente con il codice legacy" ha esempi in Java, ma il libro non tratta di risolvere questo problema solo in Java. Può essere, ed è applicato, in una varietà di lingue.
Talvolta è anche la soluzione sbagliata semplicemente perché un progetto verificabile è spesso un buon progetto. Supponiamo che tu abbia una classe che contiene una serie di metodi pubblici che utilizzano tutti un singolo metodo privato di 100 righe per preparare i dati. L'unittesting di questa classe può essere problematica: si desidera testare la logica nei metodi pubblici, ma anche la verifica del metodo privato. E testare il metodo privato può essere ottenuto solo attraverso i metodi pubblici, il che rende difficile il test. L'estrazione del metodo privato in una classe separata e la dipendenza - l'iniezione non solo rende la classe più testabile, ma rende anche la classe con i metodi rimanenti più chiari: può essere più piccola, più mirata e più facile da capire.