Mantieni o elimina i test che utilizzano metodi ora privati [duplicato]

Durante la scrittura del codice orientato agli oggetti da zero, provo a seguire questi passaggi:

1. Scrivi un test che fallisce.
2. Scrivi una funzione che fa passare il test.
3. Quando sono sufficienti test e funzioni sufficienti, le funzioni refactor con firma simile in una classe .
4. Una volta completata la funzionalità della classe, rende privato il maggior numero possibile di metodi di classe.

L'ultimo passaggio mi sembra valido, dal momento che l'orientamento all'oggetto è tutto incentrato sulla complessità dietro le astrazioni e mantiene la parte pubblica di quelle astrazioni il più piccola possibile.

Tuttavia, questo mi porta a scartare molti dei test che ho scritto lavorando ancora con le semplici funzioni, poiché ora stanno testando la parte privata dell'API di una classe. Questo mi mette a disagio perché:

• i restanti test vengono improvvisamente forzati a "coprire più complessità" .

  Per esempio: se ho scritto un metodo su swap_rows in una matrice durante l'inversione, ma quel metodo è ora privato e usato solo dal metodo pubblico invert , allora test_invert deve in qualche modo trasmettere al lettore che "lo scambio di righe avviene durante l'inversione".

  Ancora più importante, quel test rimanente forse non determinerà che è lo scambio di righe che è stato rotto da un cambiamento incurante (e non da qualsiasi altra parte del processo di inversione).

• I metodi di classi private possono diventare di nuovo pubblici quando si scrive codice client che ha una causa ragionevole per accedere ai risultati.

  Questo è difficile da prevedere. È possibile ripristinare i test da un commit precedente ma è come perdere tempo.

Una soluzione sarebbe quella di rifattorizzare i metodi in una classe helper che è un pacchetto privato. Tuttavia, questo sembra un abuso di principi orientati agli oggetti per il bene dei principi del TDD; inoltre, mi chiedo se ci sarà mai una buona ragione per fare qualcosa di privato.

Mi rendo conto che sto chiedendo qui "come far crescere un progetto architettonico", e che questo non può essere fatto in un approccio completamente "dal basso verso l'alto"; ma vorrei dei consigli pratici su come mantenere o scartare questi primi test, mentre continuavo a capire la forma di un software.

Questa domanda è simile, ma qui Non metto in dubbio che sia possibile ottenere un'API pubblica iniziale direttamente con TDD: cerco buoni consigli su come arrivarci. Questa risposta è utile, ma non penso che sto cercando di adattare la mia codifica ai miei test, ma piuttosto il mio prova per il mio - ancora incerto - design.

Riassumendo: dovrei tenere o scartare i primi test mentre sto scrivendo il codice orientato agli oggetti da zero? Dovrei ancora sforzarmi di rendere privato il maggior numero possibile di metodi, o questo mi porta a una cattiva progettazione e la rimozione forzata di test è solo un sintomo di ciò?