Essas responsabilidades não são do stub e sim do próprio teste.
Durante um teste um componente provavelmente usa outros componentes enviando-lhes entradas e usando seus resultados. Esses outros componentes podem causar problemas nos testes:
- Eles ainda não podem ser implementados.
- Os componentes podem ter defeitos que impedem o funcionamento dos testes ou que fazem o usuário perder muito tempo descobrindo que uma falha de teste não foi causada pelo componente.
- Eles podem dificultar a execução dos testes quando você precisar. Se o componente é um banco de dados comercial, a sua empresa talvez não tenha licenças suficientes para todos. Ou um dos componentes pode ser o hardware, que só está disponível em horários programados em um laboratório separado.
- Eles podem fazer os testes tão devagar, de maneira que os testes não sejam executados com freqüência suficiente. Por exemplo, a inicialização do banco de dados pode levar cinco minutos por teste.
- Isso pode dificultar a provocação dos componentes para produzir certos resultados. Por exemplo, você pode querer que cada método grave no disco, para tratar os erros de "disco cheio". Como ter certeza de que o disco está cheio no momento exato em que o método é chamado?
Nesse caso podemos utilizar os stubs para substituir esses componentes, eles simularão um comportamento esperado desses componentes para o teste.
Vejam: http://www.wthreex.com/rup/portugues/process/workflow/implemen/co_stubs.htm