Michael Feathers on testing private methods

Da un articolo di InfoQ, la posizione di M.Feathers sul testare i metodi privati:

Michael Feathers suggested last year in The Deep Synergy Between Testability and Good Design that TDD encourages good design and, conversely, code that is not testable should make us think twice:

When I write tests and I have the urge to test a private method, I take it as a hint. The hint tells me that my class is encapsulating so much that it has ceased to be “understandable” by tests through its public interface. I listen to the hint, and factor my design differently. Usually, I end up moving the private method (and possibly some methods around it) to a new class where it can be non-private and accessible to tests.

Condivido al 100%!

E interessante anche quello che dice dopo, nel post originale, riguardo alla relazione tra coupling, cohesion e testabilita’.

In the end, it all comes down to cohesion and coupling.  If classes are deeply coupled with their neighbors, it is hard to control them in a test or observe them independently.  If a class isn’t cohesive, it may have some logic which is not easily exercisable through its public interface.

It seems that reverse is true also.  Classes which are hard to instantiate and use in a test harness are more coupled than they could be, and classes with private methods that you feel the urge to test, invariably have some sort of cohesion problem: they have more than one responsibility.

Advertisements

[Oracle Tips] Monitorare le connessioni aperte verso il db

Ogni volta che mi serve tenere d’occhio le connessioni verso un db Oracle mi ricordo vagamente della tabella Vqualcosa, ma il ricordo non e’ mai abbastanza nitido… Pertanto mi segno qui alcune query utili, una volta per tutte!

Per contare le connessioni aperte verso il db raggruppate per macchina client

select MACHINE, count(*) from V$SESSION group by MACHINE

Per contare solo quelle verso un certo schema

select MACHINE, count(*) from V$SESSION where schemaname = '<NOME DELLO SCHEMA>' group by MACHINE

Per contare solo quelle provenienti da certi client

select MACHINE, count(*) from V$SESSION where upper(machine) like '%<NOME DELLA MACCHINA CLIENT>%' group by MACHINE

Per contare le connessioni aperte verso il db raggruppate per utente

select osuser, count(*) from V$SESSION group by osuser;

Per contare tutte le connessioni aperte (vabbe’, questa e’ banale!)

select count(*) from V$SESSION;

Per vedere anche lo stato della connessione

select count(*), status from V$SESSION group by status;

[a-ha! moment] Finalmente ho capito la configurazione di DBCP

Questo post e’ piu’ che altro indirizzato a me stesso nel futuro, ma ovviamente se potesse servire ad altri, ora o nel futuro, ne saro’ contento.

Ho finalmente capito il significato dei parametri di configurazione di DBCP!
I miei dubbi riguardavano in particolare i parametri minIdle, maxIdle e maxActive.

Le connessioni aperte in un dato istante possono potenzialmente essere comprese tra zero e maxActive.

Quando il n. di connessioni aperte e’ compreso tra maxIdle e maxActive, tutte le connessioni ritornate al pool saranno immediatamente chiuse dal pool.

Quando il n. di connessioni aperte e’ compreso tra minIdle e maxIdle, tutte le connessioni ritornate al pool saranno soggette all’eventuale evictor (che si attiva con la prop timeBetweenEvictionRunsMillis). Questo significa che quando l’evictor parte, chiudera’ tutte le connessioni in eccedenza (rispetto a minIdle), ovviamente secondo le impostazioni dei parametri numTestsPerEvictionRun e minEvictableIdleTimeMillis (quest’ultima in particolare indica quando tempo una connessione ‘in eccesso’ puo’ rimanere idle nel pool prima di essere considerata ‘chiudibile’ dall’evictor thread).

Quando il n. di connessioni aperte e’ compreso tra zero e minIdle, tutte le connessioni ritornate al pool saranno lasciate nel pool. In altre parole non si dovrebbe mai scendere al di sotto di minIdle connessioni aperte verso il db.

Ora, magari questo puo’ sembrare scontato a voi, ma a me no! DBCP ha una documentazione piuttosto fumosa, e in particolare faccio ancora fatica a capire la differenza tra i vari parametri di configurazione… per esempio, cosa si intende per abandonedConnection? E come si distingue da una normale connessione idle?

Comunque intanto mi godo il mio a-ha! moment :)