Desenvolvimento ágil e C++

[Caio]

Boa noite senhores,

comecei a programar em C++ h� uns 6 meses.
Antes disso desenvolvi majoritariamente em Java, Python e R.

Eu sempre fui muito adepto a pr�ticas �geis expecialmente TDD (Test
Driven Development) - n�o consigo confiar em um c�digo que eu n�o tenho
um conjunto de testes que o valide.

Em geral, eu estou conseguindo escrever programas C++ usando TDD, mas
com uma boa dose de dificuldade, especialmente quando se trata de alguns
programas de baixo n�vel.

Eu estava conformado com a dificuldade, e at� a aparente
impossibilidade, de testar certas funcionalidades at� que eu li um
artigo [1] falando sobre o uso de linux em aplica��es espaciais no qual
relata-se que os programas desenvolvidos pela empresa possuem 100% de
cobertura por testes automatizados.

Com base nisso, gostaria de saber se h� aqui na lista quem desenvolva em
C++ seguindo TDD e, caso haja, que frameworks utiliza, t�cnicas,
conselhos, mandingas, etc.

Eu, particularmente, tenho utilizado googletest e googlemock (n�o sei se
com muito sucesso, =)).

Abs,
Caio

[1] http://lwn.net/Articles/540368/

[Thiago A. Corrêa]

Olá,

Na verdade, diz o artigo:

"Everyone here has 100% unit test coverage", he joked, but running
whatever tests are available, and creating new ones is useful.

Que é algo como:
"Todo mundo aqui tem 100% de cobertura de testes unitários", disse
brincando, mas rodar qualquer teste disponivel e criar novos é útil.


Para muitas coisas realmente é dificil de escrever um teste.

Att.
Thiago A. Correa

2013/3/24 Caio <caiorc...@gmail.com>:
> Boa noite senhores,
>
> comecei a programar em C++ há uns 6 meses.

> Antes disso desenvolvi majoritariamente em Java, Python e R.
>

> Eu sempre fui muito adepto a práticas ágeis expecialmente TDD (Test Driven
> Development) - não consigo confiar em um código que eu não tenho um conjunto

> de testes que o valide.
>
> Em geral, eu estou conseguindo escrever programas C++ usando TDD, mas com
> uma boa dose de dificuldade, especialmente quando se trata de alguns

> programas de baixo nível.
>
> Eu estava conformado com a dificuldade, e até a aparente impossibilidade, de
> testar certas funcionalidades até que eu li um artigo [1] falando sobre o
> uso de linux em aplicações espaciais no qual relata-se que os programas

> desenvolvidos pela empresa possuem 100% de cobertura por testes
> automatizados.
>

> Com base nisso, gostaria de saber se há aqui na lista quem desenvolva em C++
> seguindo TDD e, caso haja, que frameworks utiliza, técnicas, conselhos,
> mandingas, etc.
>
> Eu, particularmente, tenho utilizado googletest e googlemock (não sei se com

> muito sucesso, =)).
>
> Abs,
> Caio
>
> [1] http://lwn.net/Articles/540368/
>
>
>

> --
> Antes de enviar um e-mail para o grupo leia:
> http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
> --~--~---------~--~----~---------------------------------~----------~--~----~
> [&] C & C++ Brasil - http://www.ccppbrasil.org/
> Para sair dessa lista, envie um e-mail para
> ccppbrasil-...@googlegroups.com
> Para mais opções, visite http://groups.google.com/group/ccppbrasil
> --~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
> Emprego & carreira: vag...@ccppbrasil.org
> http://groups.google.com/group/dev-guys?hl=en
>
>
>

[Caio]

On 03/24/2013 11:53 PM, Thiago A. Corr�a wrote:
> Ol�,

>
> Na verdade, diz o artigo:
>
> "Everyone here has 100% unit test coverage", he joked, but running
> whatever tests are available, and creating new ones is useful.

Tem raz�o, li errado...
> Que � algo como:
> "Todo mundo aqui tem 100% de cobertura de testes unit�rios", disse
> brincando, mas rodar qualquer teste disponivel e criar novos � �til.
>
>
> Para muitas coisas realmente � dificil de escrever um teste.

>
> Att.
> Thiago A. Correa
>
> 2013/3/24 Caio <caiorc...@gmail.com>:
>> Boa noite senhores,
>>

>> comecei a programar em C++ h� uns 6 meses.

>> Antes disso desenvolvi majoritariamente em Java, Python e R.
>>

>> Eu sempre fui muito adepto a pr�ticas �geis expecialmente TDD (Test Driven

>> Development) - n�o consigo confiar em um c�digo que eu n�o tenho um conjunto

>> de testes que o valide.
>>
>> Em geral, eu estou conseguindo escrever programas C++ usando TDD, mas com
>> uma boa dose de dificuldade, especialmente quando se trata de alguns

>> programas de baixo n�vel.
>>
>> Eu estava conformado com a dificuldade, e at� a aparente impossibilidade, de
>> testar certas funcionalidades at� que eu li um artigo [1] falando sobre o
>> uso de linux em aplica��es espaciais no qual relata-se que os programas

>> desenvolvidos pela empresa possuem 100% de cobertura por testes
>> automatizados.
>>

>> Com base nisso, gostaria de saber se h� aqui na lista quem desenvolva em C++
>> seguindo TDD e, caso haja, que frameworks utiliza, t�cnicas, conselhos,
>> mandingas, etc.
>>
>> Eu, particularmente, tenho utilizado googletest e googlemock (n�o sei se com

>> muito sucesso, =)).
>>
>> Abs,
>> Caio
>>
>> [1] http://lwn.net/Articles/540368/
>>
>>
>>
>> --
>> Antes de enviar um e-mail para o grupo leia:
>> http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
>> --~--~---------~--~----~---------------------------------~----------~--~----~
>> [&] C & C++ Brasil - http://www.ccppbrasil.org/
>> Para sair dessa lista, envie um e-mail para
>> ccppbrasil-...@googlegroups.com

>> Para mais op��es, visite http://groups.google.com/group/ccppbrasil

[Rodrigo Avancini]

Bom dia Caio,

Há anos "batemos cabeça" com o TDD aqui na empresa, lhe digo que é um desafio e tanto..

Já fizemos algumas pesquisas em frameworks para tentar melhorar o processo e por enquanto o CppUnit tem sido a melhor alternativa..

Também aceito tenho interesse em sugestões aqui no grupo..

Att.

Rodrigo

Em 25 de março de 2013 01:09, Caio <caiorc...@gmail.com> escreveu:

On 03/24/2013 11:53 PM, Thiago A. Corrêa wrote:

Olá,

     Na verdade, diz o artigo:

  "Everyone here has 100% unit test coverage", he joked, but running
whatever tests are available, and creating new ones is useful.

Tem razão, li errado...

     Que é algo como:
  "Todo mundo aqui tem 100% de cobertura de testes unitários", disse

brincando, mas rodar qualquer teste disponivel e criar novos é útil.

    Para muitas coisas realmente é dificil de escrever um teste.

Att.
     Thiago A. Correa

2013/3/24 Caio <caiorc...@gmail.com>:

Boa noite senhores,

comecei a programar em C++ há uns 6 meses.

Antes disso desenvolvi majoritariamente em Java, Python e R.

Eu sempre fui muito adepto a práticas ágeis expecialmente TDD (Test Driven
Development) - não consigo confiar em um código que eu não tenho um conjunto

de testes que o valide.

Em geral, eu estou conseguindo escrever programas C++ usando TDD, mas com
uma boa dose de dificuldade, especialmente quando se trata de alguns

programas de baixo nível.

Eu estava conformado com a dificuldade, e até a aparente impossibilidade, de
testar certas funcionalidades até que eu li um artigo [1] falando sobre o
uso de linux em aplicações espaciais no qual relata-se que os programas

desenvolvidos pela empresa possuem 100% de cobertura por testes
automatizados.

Com base nisso, gostaria de saber se há aqui na lista quem desenvolva em C++
seguindo TDD e, caso haja, que frameworks utiliza, técnicas, conselhos,
mandingas, etc.

Eu, particularmente, tenho utilizado googletest e googlemock (não sei se com

muito sucesso, =)).

Abs,
Caio

[1] http://lwn.net/Articles/540368/



--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para

ccppbrasil-unsubscribe@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil

--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira:  vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en

--
Antes de enviar um e-mail para o grupo leia:                     http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] C & C++ Brasil - http://www.ccppbrasil.org/

Para sair dessa lista, envie um e-mail para ccppbrasil-unsubscribe@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil

[André Luis Pereira]

Existe a biblioteca de testes da Boost:  http://www.boost.org/doc/libs/1_42_0/libs/test/doc/html/index.html

-----------------------------------------------------------
   André Luis Pereira

Grupo BSR Participações LTDA
BSRSoft LTDA
an...@bsrpar.com

+55 (11) 4063 4108

Site: http://soft.bsrpar.com
BSRSoft DIDD: http://didd.bsrpar.com
BSRSoft ServerUX on FreeBSD: http://soft.bsrpar.com/2012/01/o-serverux.html

"Vai imprimir este email? Pense antes em sua responsabilidade com a
preservação do meio-ambiente e com a redução de seus custos."

--------------------------------------------------------------
"Uma corrente é tão segura quanto seu elo mais fraco"
---------------------------------------------------------------

Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com

[Rodolfo Timoteo da Silva]

http://www.typemock.com/

Att

Rodrigo

[Bruno Herrera]

tenho usado o google test e google mock e tem sido bem produtivo.

http://code.google.com/p/googletest/

2013/3/25 Rodolfo Timoteo da Silva <zhush...@gmail.com>

[Caio]

Eu acho que seria interessante discutir um pouco mais sobre essa questão de desenvolvimento orientado a testes em projetos C++.

Tem alguma empresa que esteja efetivamente fazendo TDD?

O Rodrigo Avancini comentou que a empresa em que ele trabalha tem batido cabeça para conseguir fazer TDD, será que é possível falar quais são as dificuldades?

[]s
Caio

[André Luis Pereira]

No meu caso, comecei a pouco tempo com TDD em C++, em especial em QT4 no QT Creator.

Minhas maiores dificuldades estão relacionadas às poucas opções de fácil implantação para os testes unitários e ao suporte à testes um tanto quanto capenga fornecido pelas IDEs. (antes do QT Creator eu já trabalhei com C++ no Netbeans)

Uso atualmente a biblioteca de testes da Boost, mas me faz muita falta a praticidade de JUnit e da PHPUnit que já utilizei em outros carnavais em diversas IDEs.

-----------------------------------------------------------
   André Luis Pereira

Grupo BSR Participações LTDA
BSRSoft LTDA
an...@bsrpar.com

+55 (11) 4063 4108

Site: http://soft.bsrpar.com
BSRSoft DIDD: http://didd.bsrpar.com
BSRSoft ServerUX on FreeBSD: http://soft.bsrpar.com/2012/01/o-serverux.html

"Vai imprimir este email? Pense antes em sua responsabilidade com a
preservação do meio-ambiente e com a redução de seus custos."

--------------------------------------------------------------
"Uma corrente é tão segura quanto seu elo mais fraco"
---------------------------------------------------------------

[Rodrigo Avancini]

Caio,

O maior problema mesmo (no meu caso) é que o sistema não foi concebido utilizando o TDD, alem disso tinha poucos testes unitários, o sistema também usa muitas bibliotecas gráficas e engines externas (libs, dlls), tentar reproduzir essas dependências em Mocks as vezes é uma tarefa árdua,  outro problema também é mudar a cultura dos programadores que não reconhecem o verdadeiro valor do TDD. Meu problema não ta em nível de framework (TDD) e sim em contexto de engenharia de software em geral..

Mesmo assim ainda recomendo o CppUnit, já testei vários, o que mais me agradou nele, alem das coisas básicas de framework de testes unitários deve ter, foi o "code's stardard conventions", que segue o nosso padrão adotado (lembrando que padrão de codificação é uma coisa importante que deve ser definido obrigatoriamente para quem utiliza XP)..

Att.

Rodrigo

[P.]

Em quarta-feira, 27 de março de 2013 09h00min51s UTC-3, Rodrigo Avancini escreveu:

 

O maior problema mesmo (no meu caso) é que o sistema não foi concebido utilizando o TDD, alem disso tinha poucos testes unitários, o sistema também usa muitas bibliotecas gráficas e engines externas (libs, dlls), tentar reproduzir essas dependências em Mocks as vezes é uma tarefa árdua,  outro problema também é mudar a cultura dos programadores que não reconhecem o verdadeiro valor do TDD. Meu problema não ta em nível de framework (TDD) e sim em contexto de engenharia de software em geral..

Este também foi o problema quando fracassei numa tentativa de introduzir TDD em uma certa empresa.
O nível de encapsulamento necessário para aplicar TDD adequadamente é mais alto que era considerado "suficiente" pelos responsáveis do projeto.
Apontar a impossibilidade de isolar módulo X ou Y para construir um teste automatizado sucistava respostas do tipo "as coisas são assim mesmo", ou "teste automatizado não se aplica ao nosso caso" etc.
Mesmo após aplicar a técnica de componentização do "UML Components" em um pedacinho do sistema e exibir uma suite de testes automatizados com cppunit a idéia não pegou.
Era "impossível".
Manobrar os seres humanos é infinitamente mais difícil que manobrar os compiladores etc.

--
 P.

[André Luis Pereira]

Parece extremamente difícil mudar a cultura de décadas dos programadores C++ mesmo.

Parece que somos um ramo tradicionalista demais dentro da TI.

-----------------------------------------------------------
   André Luis Pereira

Grupo BSR Participações LTDA
BSRSoft LTDA
an...@bsrpar.com

+55 (11) 4063 4108

Site: http://soft.bsrpar.com
BSRSoft DIDD: http://didd.bsrpar.com
BSRSoft ServerUX on FreeBSD: http://soft.bsrpar.com/2012/01/o-serverux.html

"Vai imprimir este email? Pense antes em sua responsabilidade com a
preservação do meio-ambiente e com a redução de seus custos."

--------------------------------------------------------------
"Uma corrente é tão segura quanto seu elo mais fraco"
---------------------------------------------------------------

--

[Gianni]

Ah... não é tão difícil assim. Eu comecei a pouco tempo usar testes unitários
(ainda não TDD, só 'D' e depois 'T' mesmo) e me acostumei rápido (por
influência do Caio mesmo).

Acho que o que falta é ter o processo bem definido. Ter um 'How-To' de boas
práticas do processo todo; de como fazer o design, depois testes,
desenvolver+documentar, validar e então colocar no profiler. Usando UML, Git,
CMake[0]/Make/QMake[1]/QBS[2], GCC, Doxygen[3], Valgrind[4]+memtool,
Valgrind+callgrind[5], Jenkins[6].

Basicamente, um exemplo de um processo usando todos esses caras.

[0] http://cmake.org/
[1] https://qt-project.org/doc/qt-4.8/qmake-manual.html
[2] https://qt-project.org/wiki/Qbs-Quick-Reference
[3] http://www.stack.nl/~dimitri/doxygen/
[4] http://valgrind.org/
[5] http://kcachegrind.sourceforge.net/html/Shot3.html
[6] https://en.wikipedia.org/wiki/Jenkins_%28software%29

> > --~ [&] C & C++ Brasil - http://www.ccppbrasil.org/

[P.]

Você, ou você e sua equipe de cinco pessoas mais as outras três equipes de cinco pessoas?

:-D

[Gianni]

Quaaase... a minha equipe aqui da lista! Eu ponho a tarefa aqui na lista e espero vcs entregarem....

 

---------- Forwarded Message ----------

From: redmine

To:

Date: Today 18:30:00

Subject: [TDD - Feature #112] (New) Criar How-To completo

 

 

Issue #112 has been reported by Nasus Maximos.

• Status changed to New
• % Done changed to 0

----------------------------------------

Bug #112: Criar How-To completo

• Author: Nasus Maximos
• Status: New
• Priority: High
• Assignee: Pedro Lamarão
• Category: Documentation
• Due date: Yesterday
• Target version: Milestone I

Ah... não é tão difícil assim. Eu comecei a pouco tempo usar testes unitários

(ainda não TDD, só 'D' e depois 'T' mesmo) e me acostumei rápido (por

influência do Caio mesmo).

 

Acho que o que falta é ter o processo bem definido. Ter um 'How-To' de boas

práticas do processo todo; de como fazer o design, depois testes,

desenvolver+documentar, validar e então colocar no profiler. Usando UML, Git,

CMake[0]/Make/QMake[1]/QBS[2], GCC, Doxygen[3], Valgrind[4]+memtool,

Valgrind+callgrind[5], Jenkins[6].

 

Basicamente, um exemplo de um processo usando todos esses caras.

 

[0] http://cmake.org/

[1] https://qt-project.org/doc/qt-4.8/qmake-manual.html

[2] https://qt-project.org/wiki/Qbs-Quick-Reference

[3] http://www.stack.nl/~dimitri/doxygen/

[4] http://valgrind.org/

[5] http://kcachegrind.sourceforge.net/html/Shot3.html

[6] https://en.wikipedia.org/wiki/Jenkins_%28software%29

 

----------------------------------------

You have received this notification because you have either subscribed to it,or are involved in it.

To change your notification preferences, please click here: http://hostname/my/account

[Otávio Basso Gomes]

Mudar a cultura realmente é a parte mais difícil do desenvolvimento agil em C++. Me espanta que muitas empresas adotam o Scrum mas esquecem de incentivar práticas ágeis para implementação em sí. Nem falo em TDD mas ter uma boa cobertura de testes. E o que mais me espanta ainda é que muitas vezes venham dos próprios programadores esse preconceito.

[Walter Mascarenhas]

  A cultura é certamente um problema. Infelizmente experiências
como a do Pedro acontecem bastante.
 
  Porém, me espanta também a confusão entre métodos ágeis
e testes. Sob o meu ponto de vista dinossáurico, testes são
FUNDAMENTAIS desde sempre. Quando comecei a programar
a sério, em 1988, eu observava um grande programador (Mike McKeena)
que trabalhava em uma velha Lisp machine do lado da minha.
Para cada linha de código ele escrevia umas quatro ou cinco
de testes.

  A companhia onde trabalhávamos (Thinking Machines) faliu e hoje
é parte da história da computação em paralelo, mas desde daqueles
tempos bons programadores, em qualquer linguagem, sabem
da importância de testes.

  Outra coisa é a religião ágil, com seus mitos e crenças. Há
muitos pontos positivos em agilidade, mas as vezes falta
um pouco de senso crítico ao pessoal que defende com
unhas e dentes esta linha de pensamento. Isto pode ser
uma das fontes de resistência à agilidade.

  De qualquer forma, seria saudável que os jovens ágeis
lessem pelo menos os livros do Doug Rosenberg, como

Design Driven Testing: Test Smarter, Not Harder 

e vissem o vídeo hilário (o cara fala a sério!!!).

 http://www.ted.com/talks/bruce_feiler_agile_programming_for_your_family.html

  A partir da consideração sem preconceito das critícas à agilidade me
parece que  ficaria mais fácil convencer os demais sobre o que  elas
tem realmente de bom. Ou melhor, focar no
que elas tem de bom e evitar o que elas tem de ridículo.

          walter.

[Marcelo Zimbres]

Vou citar aqui a opinião de um desenvolvedor com a qual simpatizo:

Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don’t improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don’t buy a new scale; change your diet. If you want to improve your software, don’t test more; develop better.

        — Steve McConnell Code Complete

Já me deparei inúmeras vezes com testes inadequados e qua não testam nada e que portanto dão a impressão errada de que tudo está ok antes de comitar. Testes na minha opinião tem que ser o mínimo que garanta o funcionamento (e não menos que o mínimo).

Marcelo

--

[Walter Mascarenhas]

    A minha opinião é diferente. Acredito que um dos pontos positivos do
enfoque ágil é a importância atribuída aos testes e a ênfase no ponto
que eles devem ser feitos o mais cedo possível.

  Pelo menos no tipo de software que eu escrevo, os testes ajudam sim
a melhorar a qualidade, tanto sob o ponto de vista de diminuição de
bugs idiotas como na detecção de problemas no design. Não chego
ao ponto de escrever os testes antes, pois considero exagero, mas
acredito que o desenvolvimento e execução de testes durante a
programação são benéficos.

  Para mim é claro também que o fator limitante é mesmo o programador.
Testes feitos por alguém que faz isto por mera obrigação ou aceitação
de dogmas terão os problemas apontados pelo Marcelo. Se o programador
não tiver consciência do que está fazendo então não adianta testar antes,
no meio ou depois. Na verdade, não adianta nem programar...

                walter.

[Caio]

On 03/28/2013 08:39 AM, Walter Mascarenhas wrote:

��� A minha opini�o � diferente. Acredito que um dos pontos positivos do
enfoque �gil � a import�ncia atribu�da aos testes e a �nfase no ponto
que eles devem ser feitos o mais cedo poss�vel.

� Pelo menos no tipo de software que eu escrevo, os testes ajudam sim
a melhorar a qualidade, tanto sob o ponto de vista de diminui��o de
bugs idiotas como na detec��o de problemas no design. N�o chego

ao ponto de escrever os testes antes, pois considero exagero, mas

acredito que o desenvolvimento e execu��o de testes durante a
programa��o s�o ben�ficos.

� Para mim � claro tamb�m que o fator limitante � mesmo o programador.
Testes feitos por algu�m que faz isto por mera obriga��o ou aceita��o
de dogmas ter�o os problemas apontados pelo Marcelo. Se o programador
n�o tiver consci�ncia do que est� fazendo ent�o n�o adianta testar antes,
no meio ou depois. Na verdade, n�o adianta nem programar...

��������������� walter.

On Thursday, March 28, 2013 7:23:29 AM UTC-3, mzimbres wrote:

Vou citar aqui a opini�o de um desenvolvedor com a qual simpatizo:

Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don�t improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don�t buy a new scale; change your diet. If you want to improve your software, don�t test more; develop better.

��������� Steve McConnell Code Complete

J� me deparei in�meras vezes com testes inadequados e qua n�o testam nada e que portanto d�o a impress�o errada de que tudo est� ok antes de comitar. Testes na minha opini�o tem que ser o m�nimo que garanta o funcionamento (e n�o menos que o m�nimo).

Marcelo

Em 28 de mar�o de 2013 06:11, Walter Mascarenhas <walter.ma...@gmail.com> escreveu:

� A cultura � certamente um problema. Infelizmente experi�ncias

como a do Pedro acontecem bastante.

�
� Por�m, me espanta tamb�m a confus�o entre m�todos �geis
e testes. Sob o meu ponto de vista dinoss�urico, testes s�o

FUNDAMENTAIS desde sempre. Quando comecei a programar

a s�rio, em 1988, eu observava um grande programador (Mike McKeena)

que trabalhava em uma velha Lisp machine do lado da minha.

Para cada linha de c�digo ele escrevia umas quatro ou cinco
de testes.

� A companhia onde trabalh�vamos (Thinking Machines) faliu e hoje
� parte da hist�ria da computa��o em paralelo, mas desde daqueles

tempos bons programadores, em qualquer linguagem, sabem

da import�ncia de testes.

� Outra coisa � a religi�o �gil, com seus mitos e cren�as. H�

muitos pontos positivos em agilidade, mas as vezes falta

um pouco de senso cr�tico ao pessoal que defende com

unhas e dentes esta linha de pensamento. Isto pode ser

uma das fontes de resist�ncia � agilidade.

� De qualquer forma, seria saud�vel que os jovens �geis

lessem pelo menos os livros do Doug Rosenberg, como

Design Driven Testing: Test Smarter, Not Harder�

e vissem o v�deo hil�rio (o cara fala a s�rio!!!).

�http://www.ted.com/talks/bruce_feiler_agile_programming_for_your_family.html

� A partir da considera��o sem preconceito das crit�cas � agilidade me
parece que� ficaria mais f�cil convencer os demais sobre o que� elas

tem realmente de bom. Ou melhor, focar no

que elas tem de bom e evitar o que elas tem de rid�culo.

��������� walter.

On Wednesday, March 27, 2013 10:24:39 PM UTC-3, Ot�vio Basso Gomes wrote:

Mudar a cultura realmente � a parte mais dif�cil do desenvolvimento agil em C++. Me espanta que muitas empresas adotam o Scrum mas esquecem de incentivar pr�ticas �geis para implementa��o em s�. Nem falo em TDD mas ter uma boa cobertura de testes. E o que mais me espanta ainda � que muitas vezes venham dos pr�prios programadores esse preconceito.

--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com

Para mais op��es, visite http://groups.google.com/group/ccppbrasil

--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira: vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en

�
�
�

--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com

Para mais op��es, visite http://groups.google.com/group/ccppbrasil

--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira: vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en

�
�
�

Acho que a discuss�o pode se manter produtiva se tentarmos evitar pontua��es evangel�sticas.

Os m�todos/pr�ticas �geis surgiram na ind�stria como resultado de uma s�rie de problemas no processo de desenvolvimento
de software. E essas pr�ticas �geis foram propostas por dinossauros tb, como Kent Beck, Martin Fowler e Alistair Cockburn [1].

Isso n�o significa, entretanto, que essas metodologias (scrum, XP, etc) sejam um algoritmo de sucesso para se desenvolver software.
E, particularmente, eu acho que qualquer empresa que sofra com o processo de desenvolvimento (falta de testes, "arquitetura" ruim, problema de prazos, etc)
deveria tentar mudar sua metodologia e, em geral, m�todos �geis pode ser uma tentativa barata.

Para quem tiver interesse em sair do n�vel da "discuss�o do caf�" e tentar olhar com mais cuidado para os pr�s e contras de m�todos �geis e o como empresas
pelo mundo tem adotado ou sofrido com esse m�todos, pode ler esse artigo [2].

Apesar de n�o ser novo, ele apresenta um resumo dos estudos emp�ricos sobre a ado��o de pr�ticas �geis em empresas de tecnologia.

Com rela��o ao TDD, talvez seja necess�rio elucidar melhor o que significa TDD. N�o trata-se apenas de escrever "testes" primeiro para ent�o escrever c�digo "de verdade".
H� um processo sugerido que come�a antes mesmo da escrita do c�digo e que, se bem aplicado, o programador n�o vai acabar com dezenas de testes, mas com os
testes que atestam o devido funcionamento de uma funcionalidade. Inclusive, uma empresa que se d� ao trabalho de escrever testes tb deve se dar ao trabalho de
refator�-los, n�o? Uma vez que o software muda, os testes tb precisam ser refatorados para n�o acabar com um conjunto de testes que n�o refletem e n�o documentem
o comportamento esperado do c�digo. E essa refatora��o no c�digo de teste � prevista no TDD.

Para quem tiver interesse, o artigo de TDD da wikipedia parace ser um bom come�o [3].

Com rela��o ao issue criado pelo Gianni e atribu�do ao Pedro, eu j� estava pensando em fazer um "how to" sobre TDD e C++, desenvolvendo uma aplica��o mais
interessante que uma classe Calculadora em TDD.

[]s
Caio

[1] http://agilemanifesto.org/
[2] http://dl.acm.org/citation.cfm?id=1379989
[3] http://en.wikipedia.org/wiki/Test-driven_development

[Otávio Basso Gomes]

Quando falei de preconceito falei de preconceito de testes mesmo.

Sem entrar no mérito de ser TDD ou outros tipos de testing... Escrever testes para pelo menos cada modulo ou funcionalidade do sistema ajudam a desenvolver melhor na minha opinião, pois simplesmente deixam mais rápido o ciclo compile-debug-test. Além facilitar a vida dos outros programadores para resolver futuros bugs, é bem mais agil de isolar problemas.

Agora quanto a granularidade de testes, é algo difícil de ser acertado e depende da aplicação. 

Otávio

2013/3/28 Marcelo Zimbres <mzim...@gmail.com>

[Walter Mascarenhas]

>> Para quem tiver interesse em sair do n�vel da "discuss�o do caf�" e tentar olhar com mais cuidado para os pr�s e contras de m�todos �geis e o como empresas
>> pelo mundo tem adotado ou sofrido com esse m�todos, pode ler esse artigo [2].

 Temos aqui um bom exemplo da religião ágil: o sujeito (Caio) classifica a opinião dos outros
como discussão de café, como se só ele "olhasse com cuidado as práticas e métodos...".
Para exemplificar a sua sabedoria ele cita como referência um artigo de cinco anos atrás
cuja conclusão principal parece ser que mais estudos são necessários:

"The main implication for research is a need for more and better empirical studies of agile software
development within a common research agenda."

 tenha paciência e me tragam mais café....

[Caio]

Para mais opções, visite http://groups.google.com/group/ccppbrasil

--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira: vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en
 
 
 

Caro Walter, creio que não fui suficientemente claro. Por "sair do nível da discussão do café" não me limitei aos argumentos contra práticas ágeis, mas me referi também aos a favor.
Em geral essas discussões sobre práticas ágeis se baseiam em achismos e ninguém acaba citando um estudo que olhe de forma crítica e imparcial para o problema.
Eu citei um artigo que faz justamente isso. Se vc ler mais do que o abstract do artigo verá que ele colabora com a discussão mostrando pontos de sucesso e de fracasso,
pontos fortes e fracos, sobre o uso de métodos ágeis, mostrando que esses métodos e práticas não são um santo graal, e que podem ser ruins para determinadas empresas.

Não sou um evangelista ágil, sou pragmático. Se surgirem os métodos espaciais e eles de fato melhorarem o processo de desenvolvimento então eu serei um programador espacial.
Para mim, não importa se é ágil, cascata, ponto de função, code and fix, etc.
O que importa é se funciona.

[]s
Caio

[Walter Mascarenhas]

Caro Walter, creio que não fui suficientemente claro. Por "sair do nível da discussão do café" não me limitei aos argumentos contra práticas ágeis, mas me referi também aos a favor.

  Caro Caio,

     Você foi muito claro, tanto que insiste na superioridade da sua sapiência na sua resposta:
 

Em geral essas discussões sobre práticas ágeis se baseiam em achismos e ninguém acaba citando um estudo que olhe de forma crítica e imparcial para o problema.

  Ou seja, nestas discussões NINGUÉM além de você pensa de forma crítica e imparcial.
  Para você, os outros apenas "acham", pois não leram além do abstract do artigo maravilhoso
que você achou.

   Quando eu tiver tempo eu leio o resto do artigo que você achou e te digo o que eu acho.

                  walter.

 

[Thiago Adams]

2013/3/28 Marcelo Zimbres <mzim...@gmail.com>

Vou citar aqui a opinião de um desenvolvedor com a qual simpatizo:

Testing by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don’t improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don’t buy a new scale; change your diet. If you want to improve your software, don’t test more; develop better.

        — Steve McConnell Code Complete

Já me deparei inúmeras vezes com testes inadequados e qua não testam nada e que portanto dão a impressão errada de que tudo está ok antes de comitar. Testes na minha opinião tem que ser o mínimo que garanta o funcionamento (e não menos que o mínimo).

Tenho esta opinião também.

[Thiago Adams]

2013/3/28 Walter Mascarenhas <walter.ma...@gmail.com>

...

 

 Porém, me espanta também a confusão entre métodos ágeis
e testes. Sob o meu ponto de vista dinossáurico, testes são
FUNDAMENTAIS desde sempre. 

 

Eu também acho.

Certas mensagens desta thread passaram-me  a impressão que programadores mais antigos C++ seriam contra a "modernidade" de testes.

Na verdade todo programador profissional não vai entregar um software não testado. A questão do método de ir testando antes de ter o código pronto é apenas uma receita (do tipo testar entradas) e para um programador experiente é o mesmo que dizer "olhe para os dois lados antes de atravessar a rua"

 

[Caio]

On 03/28/2013 10:42 AM, Walter Mascarenhas wrote:

Caro Walter, creio que não fui suficientemente claro. Por "sair do nível da discussão do café" não me limitei aos argumentos contra práticas ágeis, mas me referi também aos a favor.

  Caro Caio,

     Você foi muito claro, tanto que insiste na superioridade da sua sapiência na sua resposta:

Caro Walter, não gostaria de prolongar a discussão dessa forma, porém não consigo deixar de responder ao que vc disse e que considero injusto.
Não há superioridade alguma aqui.

Eu, felizmente ou infelizmente, tive na faculdade o curso de Engenharia de Software fortemente focado em métodos
ágeis e nesse curso tivemos que, além de aprender sobre esses métodos, ler diversos artigos relatando estudos de casos sobre a aplicação desses métodos.
Ao ler esses artigos fica claro que não há santo graal e que, como vc mesmo disse, há aspectos positivos e negativos nessas práticas.

Veja que não há superioridade alguma nisso, apenas li artigos que vc não leu. E que, se alguém quiser saber sobre pontos fortes e fracos dessas coisas
pode recorrer a um artigo que, supostamente, analisa a questão de um ponto de vista academico e imparcial.

Eu só não gostaria que essa discussão se tornasse uma discussão de evangelismo, que em geral não são protutivas.
Eu estou tendo dificuldade em um problema e gostaria de saber se alguém teria passado por situação parecida para poder me ajudar.

[]s
Caio

 

Em geral essas discussões sobre práticas ágeis se baseiam em achismos e ninguém acaba citando um estudo que olhe de forma crítica e imparcial para o problema.

  Ou seja, nestas discussões NINGUÉM além de você pensa de forma crítica e imparcial.
  Para você, os outros apenas "acham", pois não leram além do abstract do artigo maravilhoso
que você achou.

   Quando eu tiver tempo eu leio o resto do artigo que você achou e te digo o que eu acho.

                  walter.

 

Eu citei um artigo que faz justamente isso. Se vc ler mais do que o abstract do artigo verá que ele colabora com a discussão mostrando pontos de sucesso e de fracasso,
pontos fortes e fracos, sobre o uso de métodos ágeis, mostrando que esses métodos e práticas não são um santo graal, e que podem ser ruins para determinadas empresas.

Não sou um evangelista ágil, sou pragmático. Se surgirem os métodos espaciais e eles de fato melhorarem o processo de desenvolvimento então eu serei um programador espacial.
Para mim, não importa se é ágil, cascata, ponto de função, code and fix, etc.
O que importa é se funciona.

[]s
Caio

--

[Walter Mascarenhas]

 
   Caio,

     O fato de você ter tido um estudo tão cuidadoso sobre
métodos ágeis na faculdade é muito positivo, principalmente
por ter sido do modo crítico que você menciona.

    Você deve ter lido vários artigos que eu não li e encarado
o assunto sob ângulos que eu não considerei. Isso não
me incomoda nem um pouco: é natural que pessoas vejam
as coisas diferente de mim e saibam coisas que eu não sei.
Sõ um idiota acredita que sabe tudo e está sempre certo.

   O que me incomoda é a sua suposição quanto ao que eu,
e outros membros desta lista sabemos ou deixamos de
saber ou lemos ou deixamos de ler. Você não faz idéia do
que eu já estudei e dos projetos práticos de que participei,
assim como eu não faço idéia do que você estudou e da
sua experiência prática.

   Foi isso que me incomodou na sua mensagem. De novo, o fato
de você saber algo que eu não sei ou ver as coisas de modo
diferente não me incomoda nem um pouco. Se incomodasse
eu não participaria da lista e ficaria em casa me olhando no
espelho e admirando a minha sabedoria infinita.

               water.

[Gianni .]

On Thursday 28 March 2013 08:20:53 Walter Mascarenhas wrote:

[...snip...]

   O que me incomoda é a sua suposição quanto ao que eu,
e outros membros desta lista sabemos ou deixamos de
saber ou lemos ou deixamos de ler. Você não faz idéia do
que eu já estudei e dos projetos práticos de que participei,
assim como eu não faço idéia do que você estudou e da
sua experiência prática.

[...snip...]

 

 

Cara, não foi isso que foi dito. Nem próximo disso. Você está seriamente descaracterizando o que o Caio disse, que foi de formas beeem gerais, e fazendo parecer que o Caio estava falando exclusivamente de você.

 

A ideia era sair do teórico e começar a discutir a prática. Se você não concorda com os métodos ágeis ou algo assim, abstênha-se da discussão... Isso que você falou foi desnecessário, não acrescentou nada, descaracterizou o contexo de 'em termos gerais' em um suposto ataque ad-hominem... enfim, só atrapalha.

[André Luis Pereira]

Boa tarde.

Alguém já usou TDD aqui com o framework QT?

Caso sim, poderiam compartilhar suas experiências?

Obrigado.

-----------------------------------------------------------
   André Luis Pereira

Grupo BSR Participações LTDA
BSRSoft LTDA
an...@bsrpar.com

+55 (11) 4063 4108

Site: http://soft.bsrpar.com
BSRSoft DIDD: http://didd.bsrpar.com
BSRSoft ServerUX on FreeBSD: http://soft.bsrpar.com/2012/01/o-serverux.html

"Vai imprimir este email? Pense antes em sua responsabilidade com a
preservação do meio-ambiente e com a redução de seus custos."

--------------------------------------------------------------
"Uma corrente é tão segura quanto seu elo mais fraco"
---------------------------------------------------------------

--

[Rodrigo Madera]

2013/3/28 André Luis Pereira <an...@bsrpar.com>

Alguém já usou TDD aqui com o framework QT?

Excelente pergunta.

Estava com essa dúvida também, já que o Jav.. digo, Qt oferece muitos recursos de "reflection".

Vocês tem brincado com isso?

Mx

[Rodrigo 'Skhaz' Delduca]

Já[1], mas apenas o arroz com feijão...

1 - http://qt-project.org/doc/qt-5.0/qttestlib/qtest-overview.html

> Estava com essa dúvida também, já que o Jav.. digo, Qt oferece muitos recursos de "reflection".

Mais respeito com o melhor framework do mundo ;-P /troll

--
http://www.nullonerror.org/
-- flipping bits whilst updating pixels

[Rodrigo Madera]

On Thu, Mar 28, 2013 at 2:22 PM, Rodrigo 'Skhaz' Delduca <rodrigo...@gmail.com> wrote:

Mais respeito com o melhor framework do mundo ;-P /troll

Como assim? Que desrespeito é esse! Olha, você pode ter estu...

Brincadeira. 

Valews, Skhaz!!

=P

Mx

[Gianni .]

On Thursday 28 March 2013 13:22:56 Rodrigo 'Skhaz' Delduca wrote:
> Já[1], mas apenas o arroz com feijão...
>
> 1 - http://qt-project.org/doc/qt-5.0/qttestlib/qtest-overview.html
>
> > Estava com essa dúvida também, já que o Jav.. digo, Qt oferece muitos
> > recursos de "reflection".
> Mais respeito com o melhor framework do mundo ;-P /troll

Como assim? Ele não estava falando mal do MFC!

[P.]

Em quinta-feira, 28 de março de 2013 14h15min32s UTC-3, Rodrigo Madera escreveu:

 

2013/3/28 André Luis Pereira <an...@bsrpar.com>

Alguém já usou TDD aqui com o framework QT?

Excelente pergunta.

Estava com essa dúvida também, já que o Jav.. digo, Qt oferece muitos recursos de "reflection".

Acho que ai não está o segredo, bem como não está na existência de cppunit, ou cpptest ou qualquer outra coisa do tipo.
Os frameworks não oferecem mais que um método de organização e um driver de testes pré-concebido.

O segredo está na testabilidade das unidades do sistema alvo.
O nível de encapsulamento de unidades, separação de preocupações entre módulos e desacoplamento típico dos projetos já não alcança nem mesmo a suficiência para fins de manutenibilidade -- i.e. a arquitetura típica não permite mesmo corrigir bugs sem tocar em infinitos arquivos de código-fonte.

O nível de qualidade para se atingir testabilidade é muito maior.
O isolamento mais favorável aos testes de unidade está no nível das DLL ou DSO.
Considera o que significa trazer um mísero *.o na carga de um teste de unidade -- qual é o efeito colateral da inicialização dos estáticos dali?

Programas como o GCC alcançam a testabilidade como consequência da sua interface com o shell -- entra texto, sai binário -- de modo que a suite de testes se dá exatamente nesse nível -- um monte de textos de entrada e expectativas sobre a saída.
Porém, isso não caracteriza teste de unidade, o que é ruim.
Para alcançar o objetivo do método ágil -- refatorar sem medo -- é preciso testar unidades menores, e obter a salvação das aparências componente a componente.

Daí, mesmo o programa mais simples se torna um problema.
E o programa de relatórios que extrai dados do banco de dados?
Se ele é ligado diretamente a libmysql.so da vida, como pode-se realizar um testes de unidade que não depende de libmysql.so?
Por que, afinal, se eu tenho que carregar um driver de banco de dados inteiro junto do teste, não estamos testando uma única unidade certo.

Exige-se então a inserção de camadas de isolamento que parecem a princípio totalmente inúteis.
Pedaços do sistema que você jamais tornaria substituíveis na produção ainda assim devem ser encapsulados e tornados substituíveis -- porque o teste de unidade, esse sim, substituirá essa unidade por outra -- os milagrosos mocks.
Tudo isso causa pressão para que mesmo o programa mais simplório exiba a "complexidade" de padrões de projeto como MPV etc.

O compromisso em sistemas C e C++ tende a ser o teste de unidades como função ou classe.
É razoável que se faça isso, mas o problema permanece.
Mesmo que o teste de unidade seja um programa que inclui diretamente o *.o que define a função ou classe, de modo a não necessitar DLL ou DSO, ainda resta que este *.o deve ter uma interface bem definida e isolada das outras.
A consequência é incluir um *.o e não conseguir linkar o teste de unidade, porque este *.o depende de milhares de outros, novamente descaracterizando o teste de uma única unidade.
Não importa me que nível, a testabilidade exige alto nível de encapsulamento.

E convencer a equipe de que essa "complexidade" vai se pagar no futuro é difícil.
Esse é o mistério.
Framework não resolve esse mistério.

No exercício citado por mim anteriormente, eu cheguei ao ponto de criar definições "stub" para classes e métodos totalmente irrelevantes ao meu teste com o objetivo de ligar com sucesso o programa de teste -- e no meu caso o objeto do teste era um DSO de um sistema de componentes feito em casa (argh).

--
 P.

[Rodrigo Avancini]

P., por acaso você esta trabalhando no mesmo sistema que eu?.. Rss

Brincadeiras a parte, compartilho o mesmo sentimento descrito pelo P. sobre testes, vivo isso na pele..

Outra coisa que gostaria de adicionar, é que no mundo real software são feitos para clientes com dinheiro finito, ou seja, não pense em fazer testes de ônibus espacial para um projeto que paga somente um carrinho de rolimã..

Att.

Rodrigo

--

[Walter Mascarenhas]

  Neste exato momento estou usando Qt 5.0.1 com gcc 4.7.2 e boost::test
para testar código numérico. Funciona, mas como o Pedro disse, boost::test
é só uma ferramenta que ajuda na organização das coisas e me leva a pensar
melhor na estrutura do código. Por isso creio que testar antes acrescenta
algo á qualidade do código e os testes são mais que uma simples medida
de qualidade, mas a coisa toda ainda precisa evoluir muito.
 
   Por exemplo, neste esquema QT + boost::test refatorações ainda dão um
trabalhão toda vez que detecto um furo razoável na arquitetura. O módulo
de testes do QT me ajudaria neste sentido? De que forma? Alguém conhece
outra ferramenta que vá além disso?


             walter.

[Thiago Adams]

On Mar 28, 2:41 pm, "P." <pedro.lama...@gmail.com> wrote:
...

> Acho que ai não está o segredo, bem como não está na existência de cppunit,
> ou cpptest ou qualquer outra coisa do tipo.
> Os frameworks não oferecem mais que um método de organização e um driver de
> testes pré-concebido.

O que vai além de um simples framework é o code coverage
O VC++ 2012 possui unittests e relatório no IDE do code coverage
mostrando o % e as linhas testadas.

[Walter Mascarenhas]

  Thiago,

     Deixei de usar o VC++ há um tempinho (ele não suporta
template aliases, de que eu preciso). Há uma ferramenta
open source similar (para Linux)?

     Até que ponto o "code coverage" é efetivo? Ou seja,
será que os bugs mais chatos não surgem justamente
de combinações esquisitas do input, que levam à
execução de linhas que foram "cobertas" individualmente
mas que quando combinadas dão problemas?
 
   Ou seja, será que o "code coverage" do VC2012 não
dá uma ilusão de segurança que não é real? Neste sentido,
o code coverage seria apenas mais uma das ferramentas
incompletas mencionadas pelo Pedro?

                walter.

[P.]

Brother, "code coverage" não é uma ferramenta, é uma métrica -- quantas linhas ou "code paths" foram exercitados numa carga de trabalho.
Qualquer profiler te dá essa métrica, como o gprof e gcov, VTune etc.

A métrica só é aplicável na prática de testes se os testes existirem, e de modo algum conhecer a existência de "code coverage" tornará o seu sistema mais testável. O problema de arquitetura permanece o problema crucial.

--
 P.

[Walter Mascarenhas]

 
   Pensei que o "code coverage" ao qual o Thiago se
   referia fosse algo mais esperto (ou espetacular...)
   que o VC2012 tivesse a oferecer.

   Thiago, é isso mesmo? O que a ferramenta do VC2012 tem
de especial?

             walter.

[P.]

Pô galera. http://en.wikipedia.org/wiki/Code_coverage

[Walter Mascarenhas]

   Pô P., será que não existe a possiblidade do Thiago ter
encontrado algo mais no "code coverage" do VC++? Vai
saber, as vezes, por questões comerciais ou sobrenaturais,
as pessoas escolhem nomes inesperados para as coisas.

   Veja por exemplo como é feita a atribuição de números
de versão do clang pela Apple. Por alguma razão ela
decidiu confundir todo mundo e atribuir os números que
ela considera conveniente.
 
    Por alguma razão mercadológica a Microsoft poderia
ter decidido fazer o mesmo. Não seria a primeira vez
que esta companhia faz coisas inesperadas. Por isso
eu gostaria de ouvir a versão do Thiago sobre o
"code coverage" do VC.

   Ou pode ser mesmo que não haja nada de novo
no "code coverage" do VC, ai o Thiago nos diz e
fica tudo resolvido sem eu ter que reinstalar o VC
para fuçar

                     walter;

[Thiago Adams]

On Mar 28, 4:52 pm, "P." <pedro.lama...@gmail.com> wrote:
> Em quinta-feira, 28 de março de 2013 16h09min34s UTC-3, Thiago Adams
> escreveu:
>
>
>
> > On Mar 28, 2:41 pm, "P." <pedro.lama...@gmail.com> wrote:
> > ...
> > > Acho que ai não está o segredo, bem como não está na existência de
> > cppunit,
> > > ou cpptest ou qualquer outra coisa do tipo.
> > > Os frameworks não oferecem mais que um método de organização e um driver
> > de
> > > testes pré-concebido.
>
> > O que vai além de um simples framework é o code coverage
> > O VC++ 2012 possui unittests e relatório no IDE do code coverage
> > mostrando o % e as linhas testadas
>
> Brother, "code coverage" não é uma ferramenta, é uma métrica -- quantas
> linhas ou "code paths" foram exercitados numa carga de trabalho.
> Qualquer profiler te dá essa métrica, como o gprof e gcov, VTune etc.

Não conheço nenhum destes.

O que eu quero dizer com "vai além de um simples framework" é que isso
não é feito por código e não faz parte de um framework de testes.

A opção que me refiro no VC++ 2012 é "Analyze code coverage for
selected tests".
É mostrado no IDE o código colorido nas linhas que foram excutadas.
Não é uma simples métrica, mas uma forma de visualizar se aquele
switch gigante está sendo testado para todos os casos.
Não sei dizer se é possível usar esta ferramenta fora dos testes do VC+
+, se fosse, seria possível pegar um framework qualquer rodar e depois
analisar o code coverage.

O que eu fazia antes de ter isso é encher o código de breakpoints e ir
removendo enquanto rodava o teste. Assim, ao término, se sobrasse
algum breakpoint era sinal que o código não tinha sido executado.

[P.]

Em quinta-feira, 28 de março de 2013 17h36min33s UTC-3, Walter Mascarenhas escreveu:

   Pô P., será que não existe a possiblidade do Thiago ter
encontrado algo mais no "code coverage" do VC++? Vai
saber, as vezes, por questões comerciais ou sobrenaturais,
as pessoas escolhem nomes inesperados para as coisas.

Eu tenho esse bagulho instalado aqui no laboratório, e o que eu vi é o que eu esperava ver: um lance de relatório mostrando as medições de cobertura obtidas pelos testes. Muitissimo legal, mas não revolucionário; Visual Studio é o último da fila a incluir essas paradas. Até o Eclipse CDT já tinha suporte.

--
P.

[Julio Cezar Novais Raffaine]

Concordo com o Pedro que "Code Coverage" é uma métrica, e não vejo diferencial nenhum no do Visual Studio senão o apelo visual que ele possui, similar ao do JUnit. Boa pergunta esta de podere usar outra suite de teste com o code coverage dele, mas acho que não. Felizmente, na versao 2012 você consegue fazer teste unitário com C++ nativo.

Um benefício dessa métrica é observar caminhos onde ou não existem testes que o estressam, ou é um estado que jamais será alcançado, criando um desperdício. Acho que o uso do teste unitário (unitário mesmo), com a cobertura de código 100% pode ser um excelente atestado da qualidade do sistema, mas não tenho evidências disso.

2013/3/28 Thiago Adams <thiago...@gmail.com>

--
Antes de enviar um e-mail para o grupo leia:
                     http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira:  vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en

--
Julio Cezar Novais Raffaine
Sistemas de Engenharia, Odebrecht SA

São Paulo, SP
http://elloxas.blogspot.com/

[Julio Cezar Novais Raffaine]

Meio perdido na discussão atual, mas acho que a prática do TDD busca direcionar o desenvolvimento para o que realmente importa, definindo de forma clara as pré e pós condições de uma dada unidade. Assim, evitamos desperdícios com códigos que não se atem as condições impostas.

Infelizmente, nunca consegui utilizar efetivamente esta técnica, especialmente em C++, mas acho que é uma deficiência minha no entendimento teórico de como escrever testes unitários. Concordo plenamente com a visão do Pedro no sentido de que aplicações bem modularizadas oferecem as premissas necessárias para o teste, e acrescentaria que se o desenvolvimento for orientado por estes, o resultado seria uma aplicação modularizada.

2013/3/28 Julio Cezar Novais Raffaine <julio.r...@gmail.com>

[Walter Mascarenhas]

  Júlio,

     Tentando clarificar a confusão (com a qual contribui muito acima, infelizmente):
    
     1) A mensagem mais significativa na thread me parece ser a do P. as 2:41pm.
         Ela resume muito bem as coisas. Talvez valesse a pena você reler essa
         mensagem do P. (eu já reli algumas vezes)
  
     2) Depois veio uma conversa discutindo uma ferramenta específica, o
         "code coverage" do Visual C++. No meu resumo das coisas, o P. tem
         razão neste ponto também: o VC++ não tem nada especial e os
         comentários da mensagem do item 1) também se aplicam ao VC++.

    Talvez fosse interessante continuarmos a conversa discutindo quais
aspectos específicos emperram o seu uso de TDD na prática. Eu não
percebo porque o C++ é "especialmente" ruim neste quesito. Porque
você acha isto? (falo por curiosidade mesmo, não quero nem defender
nem criticar o C++)

                        walter.

[Julio Cezar Novais Raffaine]

Boa parte das vezes onde vi um uso maior de testes unitários foram em linguagens dinâmicas, como Ruby e Python, onde refatorar é muito fácil, ou linguagens mesmo que estáticas tivessem reflection e ferramentas de mock bem fáceis de ser utilizadas como no Java e C#.

No meu caso especial, uso muito o Visual Studio, e acho muito pouco prático escrever os testes antes, principalmente por causa de poucas ferramentas de refatoração, não possui um esquema de mock nativo (dá pra usar o google-mock neste caso), e ou você tem suas unidades a serem testadas em uma lib, ou vc precisa ficar adicionando os *.o no projeto de testes (o que acho inconveniente dependendo do tamanho do projeto e das dependências que você possui).

Mas como havia dito, acho que o principal problema está na minha falta de domínio teórico sobre como realizar testes unitários.

2013/3/28 Walter Mascarenhas <walter.ma...@gmail.com>

[Walter Mascarenhas]

  Você desenvolve que tipo de software?

  No meu caso não há tanta necessidades dos .o's pois
de longe a maior parte do código que uso é templatizado.
As poucas libs são coisas tipo lapack. Além disso,
a maioria do meu código são algoritmos mesmo, com
entradas e saídas muito claras. Por isso eu talvez não
veja tanta diferença entre C++ e linguagens dinâmicas.

  Quanto à "teoria", não sei bem se ela vai muito além
do bom senso. Há alguém aqui na lista que conheça
uma referência não trivial sobre este assunto, que vá
além dos Kent Back's? Alguém tem uma referência
top, daquelas que você lê e fala: tai algo que valeu
a pena ter lido?

              walter.

[Felipe Magno de Almeida]

Antecipadamente peço desculpas por enviar esse email em HTML,

o Gmail aparentemente não me dá mais opção de plain/text com
o novo "reply/compose system". O que é absolutamente ridiculo :(.

2013/3/29 Walter Mascarenhas <walter.ma...@gmail.com>

  Você desenvolve que tipo de software?

  No meu caso não há tanta necessidades dos .o's pois
de longe a maior parte do código que uso é templatizado.
As poucas libs são coisas tipo lapack. Além disso,
a maioria do meu código são algoritmos mesmo, com
entradas e saídas muito claras. Por isso eu talvez não
veja tanta diferença entre C++ e linguagens dinâmicas.

  Quanto à "teoria", não sei bem se ela vai muito além
do bom senso. Há alguém aqui na lista que conheça
uma referência não trivial sobre este assunto, que vá
além dos Kent Back's? Alguém tem uma referência
top, daquelas que você lê e fala: tai algo que valeu
a pena ter lido?

Com programação genérica, que é o comumente utilizado
para programação de calculo em C++, é geralmente bem
simples construir "mocks" ou verificar a corretude dos
resultados, pois os objetos são apenas modelos dos
concepts requeridos pelos algoritmos. Substitui-los significa
apenas implementar ou adaptar outro modelo para o mesmo
concept, geralmente com pouca intrusividade (ao contrário do
requerimento normal de OO de se herdar de determinada
classe). E também geralmente os algoritmos fazem uso
de equality reasoning das propriedades salientes de cada
abstração, o que trás uma forte ferramenta de reasoning e

verificação. Eu gostaria muito que fosse assim também
em outros domínios.

 

              walter.

[]'s
--

Felipe Magno de Almeida

[Caio]

On 03/29/2013 11:50 AM, Walter Mascarenhas wrote:

  Você desenvolve que tipo de software?

  No meu caso não há tanta necessidades dos .o's pois
de longe a maior parte do código que uso é templatizado.
As poucas libs são coisas tipo lapack. Além disso,
a maioria do meu código são algoritmos mesmo, com
entradas e saídas muito claras. Por isso eu talvez não
veja tanta diferença entre C++ e linguagens dinâmicas.

  Quanto à "teoria", não sei bem se ela vai muito além
do bom senso. Há alguém aqui na lista que conheça
uma referência não trivial sobre este assunto, que vá
além dos Kent Back's? Alguém tem uma referência
top, daquelas que você lê e fala: tai algo que valeu
a pena ter lido?

Para mim a melhor referência no assunto é o livro do Kent Beck mesmo [1].

Mas, particularmente, não acho que seja necessário muita leitura para entender TDD.
É realmente muito simples. Talvez fique mais claro como é simples vendo algum tutorial ou vídeo
de alguém escrevendo um aplicação em TDD. Como já falei, estou planejando fazer isso, mas por hora
está corrido.

De qualquer modo, eu faço TDD assim:

Antes de escrever código, eu listo (ou recebo) as features da aplicação (eg. estórias de usuário, caso de uso, etc).
Imagine um tocador de áudio, vc tipicamente tem as seguintes features:

1 - Tocar áudio
2 - Carregar arquivo de áudio
3 - Carregar arquivos de áudio em um diretorio
4 - Criar lista de reprodução
5 - Salvar lista de reprodução
6 - etc

Então escolho a feature mais fundamental da aplicação ou a mais fácil de implementar primeiro (eg. que tem menos depêndencia com outras features).
Nesse caso eu começaria pela feature 1.

Faço algum design beeeeeem rústico, não estou preocupado em estar correto, apenas que funcione para essa feature.
Nesse caso, eu definiria uma classe AudioPlayer que tem um membro audioFile e um método loadFile. Pronto, esse é o meu design:

class AudioPlayer {
    File audioFile;
    void loadFile(fileName);
}

Então eu crio uma lista de testes que reflitam o comportamento da feature.
Para a F. 1 eu teria:

1 - Verificar que chamando o método loadFile passando por parâmetro um arquivo de áudio, esse arquivo é carregado no membro audioFile;
2 - Verificar que o método loadFile lança uma exceção para arquivos que não são de áudio
3 - Verificar que o método loadFile lança uma exceção para arquivos inexistentes
4 - Verificar que o método loadFile lança uma exceção para diretórios

Com a lista de testes pronta, começo a programá-los:

void testLoadFileLoadsAudioFile()
{

    player = new AudioPlayer();
    player.loadFile("/tmp/audio.ogg");
   
    assertEquals(player.getAudioFile().getFileName(), "audio.ogg");
}

Esse código nem vai compilar, pois eu não escrevi a classe AudioPlayer, mas tudo bem. É importante que TDD seja feito em baby steps.
Sim, eu concordo que pode ser um saco, principalmente para os bons programadores que não são babies. Mas isso faz parte do processo
de experimentação.

Então eu escrevo o código de produção, APENAS O SUFICIENTE PARA COMPILAR.

Vejo que o código compila e que os testes não passam.
Então eu escrevo o código MAIS SIMPLES POSSÍVEL para o teste passar.
Vejo que o teste passa.
Então eu refatoro qualquer sacanagem feita para o teste passar, verificando que o teste ainda passa!

Terminei o primeiro teste, passo para o segundo teste:

void testLoadFileRaisesExceptionWithNonAudioFile()...

Esse processo é repetido enquanto houver testes.
Conforme vc vai programando mais testes e seu programa vai tendo mais forma, quase que certamente vc terá que refatorá-lo.
E, uma vez que vc tem uma suite de testes validando o comportamento do seu software, vc faz essa refatoração sem azia, ok?

Vejam que os códigos são pseudo-código cheios de suposições, mas acho que dá para passar a mensagem.

[]s
Caio

[1] http://www.amazon.com/Test-Driven-Development-By-Example/dp/0321146530/ref=sr_1_1?ie=UTF8&qid=1364569601&sr=8-1&keywords=test+driven+development

[Walter Mascarenhas]

  Com programação genérica, que é o comumente utilizado

para programação de calculo em C++, é geralmente bem
simples construir "mocks" ou verificar a corretude dos
resultados, pois os objetos são apenas modelos dos
concepts requeridos pelos algoritmos. Substitui-los significa
apenas implementar ou adaptar outro modelo para o mesmo
concept, geralmente com pouca intrusividade (ao contrário do
requerimento normal de OO de se herdar de determinada
classe). E também geralmente os algoritmos fazem uso
de equality reasoning das propriedades salientes de cada
abstração, o que trás uma forte ferramenta de reasoning e

verificação. Eu gostaria muito que fosse assim também
em outros domínios.

  Felipe,

  Sim, você capta bem as coisas. Eu entendo que sob este
ponto de vista a minha vida é bem mais simples. Porém,
estou prestes a me meter com um tipo de software com
o qual não tenho experiência. Por isso, gostaria de ouvir
as experiências do pessoal que vive mais esta outra realidade.

[Walter Mascarenhas]

 Caio,

   Antes de mais nada, um pedido de desculpas: eu
me excedi nas respostas anteriores a você e acabei
dizendo o que náo deveria ter dito (ou pensado).

   Com certeza (dada a minha natureza) eu voltarei a
te contrariar logo logo. Não tome minhas
afirmações como ataques pessoais. São apenas
questionamentos das suas idéias, e, por favor,
pode ficar muito a vontade para questionar as
minhas também (e eu me esforço para não
cruzar a linha do razoável de novo)

  Agora de volta á discussão:
 

Para mim a melhor referência no assunto é o livro do Kent Beck mesmo [1].

  Eu não vejo graça no jeito dele, tanto que escrevo Back, ao invés de Beck toda hora.

 

Mas, particularmente, não acho que seja necessário muita leitura para entender TDD.
É realmente muito simples. Talvez fique mais claro como é simples vendo algum tutorial ou vídeo
de alguém escrevendo um aplicação em TDD. Como já falei, estou planejando fazer isso, mas por hora
está corrido.

  É exatamente o que eu penso: é uma idéia natural. Nem tem tanta
teoria. É mais uma questão de se organizar e seguir um passo de cada vez,
como você ilustra muito bem no resto da sua resposta. Na minha opinião,
um "passo a passo" como o seu já refletebem o espírito da coisa, não
há necessidade de "Teoria". Basta pegar o espírito e ir experimentando
até amadurecer a idéia.
 
  Alguém discorda ou conhece uma formulação teórica mais detalhada e efetiva?

                walter.
  

[Caio]

On 03/29/2013 05:28 PM, Walter Mascarenhas wrote:

 Caio,

   Antes de mais nada, um pedido de desculpas: eu
me excedi nas respostas anteriores a você e acabei
dizendo o que náo deveria ter dito (ou pensado).

   Com certeza (dada a minha natureza) eu voltarei a
te contrariar logo logo. Não tome minhas
afirmações como ataques pessoais. São apenas
questionamentos das suas idéias, e, por favor,
pode ficar muito a vontade para questionar as
minhas também (e eu me esforço para não
cruzar a linha do razoável de novo)

Obrigado Walter. Não há problema. Email é um meio de comunicação complicado, a mensagem transmitida é facilmente interpretada
de outra forma.

[]s
Caio

[Felipe Magno de Almeida]

Iai Walter,

2013/3/29 Walter Mascarenhas <walter.ma...@gmail.com>

Quando eu disse que gostaria muito que fosse assim tambem

em outros dominios, nao quis dizer que os dominios mudassem
para parecerem este, mas que a mentalidade de programacao
mudasse, para que o desenvolvimento se parecesse mais com

o de calculo. Aprendendo com este.

--

 

Felipe Magno de Almeida

[Julio Cezar Novais Raffaine]

Caros, não tenho duvidas quanto ao TDD, mas sim com relação aos testes e como e quais devem ser formulados para ampliar as garantias de qualidade dos produtos entregues.

Por exemplo, no exemplo do Caio, como eu posso garantir que a música está sendo tocada corretamente? Qual o nível de modularidade que devo adotar? Quais as unidades a serem consideradas? Testes de Integração?

Com relação ao que foi dito sobre os templates, concordo que eles simplificam muito a questão da ferramenta, o problema são para produtos grandes e com UI a solução não parece ser escalável.

E apenas como relato de experiência pessoal com o google-mock ... é muito difícil mockar a sobrecarga de operadores ... deve ter uma saida, mas eu não achava, acabei criando um método para tal.

Apenas como referencia, achei este material sobre testes que achei interessante pela organização: http://www.codeproject.com/Articles/5772/Advanced-Unit-Test-Part-V-Unit-Test-Patterns

Att,

2013/3/29 Felipe Magno de Almeida <felipe.m...@gmail.com>

--

Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira: vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en
 
 
 

[Caio]

On 03/29/2013 11:41 PM, Julio Cezar Novais Raffaine wrote:

Caros, não tenho duvidas quanto ao TDD, mas sim com relação aos testes e como e quais devem ser formulados para ampliar as garantias de qualidade dos produtos entregues.

Por exemplo, no exemplo do Caio, como eu posso garantir que a música está sendo tocada corretamente? Qual o nível de modularidade que devo adotar? Quais as unidades a serem consideradas? Testes de Integração?

Olá Júlio,
Dei uma pesquisada rápida sobre como tocar som em um programa C++ e achei esse link [1] do stackoverflow que explica como fazer usando o phonon.
Nesse caso, eu testaria até onde eu consigo, ou seja, verificaria que o método play() do MediaObject não lança nenhuma exceção quando setamos um MediaSource
válido para o MediaObject.

Esse aplicação é um exemplo bom pois envolve coisas que talvez não vale a pena testar. Creio que alguém devidamente capacitado poderia captar de alguma forma
obscura o stream de audio do sistema operacional e verificar que esse stream bate com o conteúdo do arquivo de áudio. Mas será que isso vale a pena?

Dependendo do projeto, vc terá interesse em validar o comportamento de bibliotecas de terceiros tb. Durante uns anos escrevi algoritmos de negociação em bolsa e eu testava
absolutamente tudo o que o tempo me permitia. Mas para um tocador de audio eu confiaria bastante nas bibliotecas.

Não entendi sua dúvida a respeito do nível de modularidade.

[]s
Caio

[1] http://stackoverflow.com/questions/4473608/how-to-play-sound-with-qt

[Walter Mascarenhas]

  Júlio,

 
>> Por exemplo, no exemplo do Caio, como eu posso garantir que a música está sendo tocada corretamente? Qual o nível de modularidade que devo adotar? Quais as unidades a serem consideradas? Testes de Integração?

   Eu não conheço respostas satisfatórias gerais para suas perguntas.
Os patterns no artigo que você sugeriu ajudam um pouco mas também
não resolvem completamente as coisas. Na minha percepção, no frigir
dos ovos a coisa vai depender mesmo do caso específico: só o Júlio
tem informação suficiente sobre o problema do Júlio para decidir
como testar.

   Claro que seria bom que fosse diferente e se alguém souber mais
eu gostaria de ouvir, Porém, teste de UI's para mim ainda parece
um desafio enorme, sobre o qual eu simplesmente não tenho
experiência para discutir.

   No caso simples (sob o ponto de vista de testes) das coisas
que eu desenvolvo há uma estrutura natural de árvore na qual
eu testo um conjunto mais básico de módulos, depois subo
um nível testando a integração deles, depois subo outro
nível etc até chegar ao topo. Talvez desse para estruturar
as coisas assim em pelo menos parte dos seus problemas,
deixando mais tempo livre para pensar nas questões
realmente difíceis do seu caso específico.

   Em resumo é isto: sob o meu ponto de vista ainda temos
muito que evoluir nesta área. Isso é ótimo, porque se tudo
estivesse pronto esse mundo seria uma chatice.


              walter.

[Gianni]

On Friday 29 Mar 2013 23:59:58 Caio wrote:
[...]

> Creio que alguém devidamente capacitado poderia captar de alguma forma
> obscura o stream de audio do sistema operacional e verificar que esse
> stream bate com o conteúdo do arquivo de áudio.

[...]

Ligar um cabo na saída Line-Out direto na entrada Line-In?

Se o foco do programa fosse o áudio, esse teste poderia valer a pena.

Eu já programei muito com set-top-boxes, que tinham muitos testes de áudio e
vídeo na linha de produção (fábrica). E bem simples fazer um teste onde se
toca um áudio, um vídeo e pergunta para o operador "tocou direito?"

Essa forma de teste pode contar no TDD? Ou seja, executar algum comando via
código, e depois pedir intervenção humana para validar o teste?

[André Luis Pereira]

Bom dia Gianni.

Em geral, em TDD os testes são automatizados. Por conta disso, um teste que necessite de intervenção humana não seria utilizado tradicionalmente.

-----------------------------------------------------------
   André Luis Pereira

Grupo BSR Participações LTDA
BSRSoft LTDA
an...@bsrpar.com

+55 (11) 4063 4108

Site: http://soft.bsrpar.com
BSRSoft DIDD: http://didd.bsrpar.com
BSRSoft ServerUX on FreeBSD: http://soft.bsrpar.com/2012/01/o-serverux.html

"Vai imprimir este email? Pense antes em sua responsabilidade com a
preservação do meio-ambiente e com a redução de seus custos."

--------------------------------------------------------------
"Uma corrente é tão segura quanto seu elo mais fraco"
---------------------------------------------------------------

[Gianni]

Sim, eu sei que 'tradicionalmente' é automatizado. Mas minha intenção é
questionar essa tradição....

A questão originalmente levantada foi como testar o tocador de áudio.

Uma forma usando intervenção humana é:

1 - Criar uma classe que toque uma sequencia de bytes conhecida.

2 - Validação humana que essa sequencia de bytes nesta classe toca bem.

3 - Criar um hash SHA dessa sequencia.

4 - Criar uma classe mock que recebe uma sequencia de bytes, e vê se o hash
SHA bate com o hash criado no passo 2.

Assim, usamos intervenção humana para criar uma biblioteca de hashes para
todos os streams de áudio que iremos testar. Daí em diante, os testes podem
ser automatizados.

Isso é só uma idéia que tive hoje, pensando 5min no assunto... será que não há
uma forma já conhecida melhor? Alguém já deve ter passado por isso e achado
uma solução melhor...


É claro que qualquer coisa que use HW sempre vai exigir outros testes mais
complexos no final, pois HW sempre encontra uma maneira que quebrar seu SW.
Digo isso pois trabalho há muitos anos com embedded, IPTV, consumer-
eletronics, etc, e sempre tem o caso que seu SW funciona perfeitamente, mas se
o HW está ligado numa antena 'espinha de peixe' ele funciona, ligado em uma
antena de condomínio ele não funciona, apesar em ambas antenas deveriam
funcionar do mesmo jeito... na teoria...

> > --~ [&] C & C++ Brasil - http://www.ccppbrasil.org/

[André Luis Pereira]

Olá Gianni,

A idéia de gerar e hashs de referência por intervenção humana para posteriormente serem utilizados com referências em testes automatizados é perfeitamente aderente ao modelo de TDD. Na verdade em uma fase anterior ao TDD, já que essa fase inicial seria a "preparação" para o TDD que é automatizado por natureza.

A vantagem dos testes automatizados é a de que tira-se da equação a possibilidade da falha humana tanto em cada teste quanto a possibilidade de esquecimento de algum teste e consequente cobertura menor dos testes, além é claro da maior velocidade que a automação traz ao processo de uma maneira geral.

Sobre software que conversa diretamente com HW e suas indissiocrasias, realmente o buraco é mais embaixo.

Quando eu comecei a programar lá em 1998 eu era estagiário em um laboratório de física na USP. Meu projeto era a construção de um driver para uma plaquinha conversora de sinais AD.

É o inferno na Terra.

Escovar bits, literalmente, em C++ e assembly é tarefa de muita paciência e humildade.

Na época minhas únicas fontes de ajuda eram news groups (nada de fóruns) da Borland nos EUA em inglês.

Por fim terminei a tarefa com sucesso, ganhei um melhor inglês e bastante experiência com programação de baixo nível.

Não conhecia TDD à época, mas posso dizer que testes eram críticos, já que falhas não eram toleradas por levarem à coisas como leituras incorretas que poderiam gerar até mesmo risco de explosão.

Aprendi a ter muita humildade fazendo software para hardware.

Um grande abraço.

-----------------------------------------------------------
   André Luis Pereira

Grupo BSR Participações LTDA
BSRSoft LTDA
an...@bsrpar.com

+55 (11) 4063 4108

Site: http://soft.bsrpar.com
BSRSoft DIDD: http://didd.bsrpar.com
BSRSoft ServerUX on FreeBSD: http://soft.bsrpar.com/2012/01/o-serverux.html

"Vai imprimir este email? Pense antes em sua responsabilidade com a
preservação do meio-ambiente e com a redução de seus custos."

--------------------------------------------------------------
"Uma corrente é tão segura quanto seu elo mais fraco"
---------------------------------------------------------------

[Felipe Magno de Almeida]

2013/3/29 Julio Cezar Novais Raffaine <julio.r...@gmail.com>

Caros, não tenho duvidas quanto ao TDD, mas sim com relação aos testes e como e quais devem ser formulados para ampliar as garantias de qualidade dos produtos entregues.

Por exemplo, no exemplo do Caio, como eu posso garantir que a música está sendo tocada corretamente? Qual o nível de modularidade que devo adotar? Quais as unidades a serem consideradas? Testes de Integração?

Com relação ao que foi dito sobre os templates, concordo que eles simplificam muito a questão da ferramenta, o problema são para produtos grandes e com UI a solução não parece ser escalável.

Eu tenho um interpretador NCL inteiro, com GUI e tudo em programação genérica aonde apropriado, e posso dizer que é *muito* mais fácil fazer testes. Isso implica porém que o programa inteiro é bem definido em cada parte, mas os contratos são feitos através de concepts.

 

E apenas como relato de experiência pessoal com o google-mock ... é muito difícil mockar a sobrecarga de operadores ... deve ter uma saida, mas eu não achava, acabei criando um método para tal.

Não vejo dificuldade alguma, só sobrecarregar os operadores? Esses, obivamente, precisam ter a mesma semântica que definida como requerimento do algoritmo. Talvez o problema seja que os seus testes estão definidos em termos de comportamento do algoritmo, ao invés de equality reasoning das entradas e saídas. Daí querer verificar quando, e quantas vezes foram chamadas o operador, ao invés de implementá-lo como requerido pelo algoritmo e testar que a saída do algoritmo representa um valor "igual" ao que se deveria para uma determinada entrada de valores.

 

Apenas como referencia, achei este material sobre testes que achei interessante pela organização: http://www.codeproject.com/Articles/5772/Advanced-Unit-Test-Part-V-Unit-Test-Patterns

Att,

[snip]

[]'s

[Gianni]

On Saturday 30 Mar 2013 12:36:48 André Luis Pereira wrote:

> TDD. Na verdade em uma fase anterior ao TDD, já que essa fase inicial seria

> a "preparação" para o TDD que é automatizado por natureza.

 

OK. Mas e se eu tiver que refatorar a classe que toca o áudio? Então eu preciso refazer os testes que exigem intervenção humana.

 

Só dizer que as intervenções humanas são parte da preparação ao TDD que é o que eu questiono. Vejo como uma boa solução ter alguns testes, o mais isolados que for possível, que usem intervenção humana para passarem.

 

Sim, ter automatizado fica melhor, mais rápido e tudo mais. Mas há casos que não serve. Só para estes ter intervenção humana é obrigatório.

 

A vantagem então em incluir esses testes como parte integral do TDD, é ao final que uma fase, rodar todos os testes automatizados, inclusive os que exigem intervenção humana, de uma forma organizada e metódica.

[André Luis Pereira]

Exatamente Gianni.

Qualquer coisa que exija preparação manual (intervenção humana) deve ser excessão e não a regra.

E deve ser anterior ao TDD.

Isso minimiza erros, agiliza as coisas e evita refatorações em cima de código não automaticamente testável, o que tira bastante da complexidade do processo todo.

-----------------------------------------------------------
   André Luis Pereira

Grupo BSR Participações LTDA
BSRSoft LTDA
an...@bsrpar.com

+55 (11) 4063 4108

Site: http://soft.bsrpar.com
BSRSoft DIDD: http://didd.bsrpar.com
BSRSoft ServerUX on FreeBSD: http://soft.bsrpar.com/2012/01/o-serverux.html

"Vai imprimir este email? Pense antes em sua responsabilidade com a
preservação do meio-ambiente e com a redução de seus custos."

--------------------------------------------------------------
"Uma corrente é tão segura quanto seu elo mais fraco"
---------------------------------------------------------------

--

[Gianni]

On Saturday 30 Mar 2013 13:45:34 André Luis Pereira wrote:

> E deve ser anterior ao TDD.

 

Então... não. Meu ponto foi exatamente o oposto disso. Eu acho que não precisa ser anterior; poderia ser parte integral, sendo repetido durante todo o desenvolvimento. Essa era a minha pergunta/sugestão original...

[Wander Lairson Costa]

Em 30 de março de 2013 10:26, Gianni <nasus....@gmail.com> escreveu:

Eu recentemente portei uma biblioteca que entre outras coisas, tinham
rotinas de som e imagem. Nestes casos, fiz exatamente isso:
intervenção humana. Para testes de UI, já vi usarem visão
computacional, com uma webcam, coloca um padrão na tela e ve se
consegue identificar esse padrão via cam.

--
Best Regards,
Wander Lairson Costa

[Felipe Magno de Almeida]

2013/3/30 Wander Lairson Costa <wander....@gmail.com>

Aonde eu trabalhava alguns anos atrás, haviam testes que precisavam ser feitos
sobre o produto final. Em hardware. E na época a empresa tinha uma equipe de
testes que faziam os testes manualmente. Me parece que teste assim de

"hardware" (há software envolvido, mas o produto final é o hardware, onde

"por detalhe de implementação" existe software dentro), testes se tornam
algo completamente diferente, que não se aplica simplesmente a TDD.

Você não pode desenvolver uma placa mãe e querer desenvolver "testes" a
priori para definir comportamento, etc. Como seria com TDD. Geralmente
usa-se VHDL e até provabilidade para corretude. E em outras coisas a
intervenção humana para verificar que o resultado final é satisfatório.

 

--
Best Regards,
Wander Lairson Costa

[André Luis Pereira]

Olá Gianni,

Sempre que testes não automatizados forem exigidos, por definição eles estarão fora do TDD.

Testes manuais e TDD são mutuamente exclusivos;

Ou você faz os testes manuais antes ou depois do TDD. Se for durante, ocorrerá a violação do princípio do TDD.

-----------------------------------------------------------
   André Luis Pereira

Grupo BSR Participações LTDA
BSRSoft LTDA
an...@bsrpar.com

+55 (11) 4063 4108

Site: http://soft.bsrpar.com
BSRSoft DIDD: http://didd.bsrpar.com
BSRSoft ServerUX on FreeBSD: http://soft.bsrpar.com/2012/01/o-serverux.html

"Vai imprimir este email? Pense antes em sua responsabilidade com a
preservação do meio-ambiente e com a redução de seus custos."

--------------------------------------------------------------
"Uma corrente é tão segura quanto seu elo mais fraco"
---------------------------------------------------------------

--

[Gianni]

On Saturday 30 Mar 2013 14:21:41 André Luis Pereira wrote:

> Ou você faz os testes manuais antes ou depois do TDD. Se for durante,

> ocorrerá a violação do princípio do TDD.

 

É isso que eu questiono! Em casos onde não se pode fazer testes totalmente automatizados, por que não criar uma forma padronizada de se fazer os testes com intervenção humana?

 

Se não é o tradicional ou for uma violação aos princípios, dane-se! Se a forma tradicional não atende neste caso, vamos evoluir e criar uma forma de incluir uma forma nova para estes casos.

 

Tradições foram feitas para serem quebradas! É assim que a humanidade evoluí! :-D

[Walter Mascarenhas]

  As tradições foram feitas para ser quebradas, claro, mas usar o
mesmo nome para a tradição antes e depois da quebra pode
causar confusão, com as pessoas usando o mesmo termo
para falar de coisas distintas.
 
  Por isso me parece que seria melhor reservar o nome "TDD" para
testes puramente automatizados, no sentido que o André tem
mencionado, e criar um outro termo ("TDD do Gianni")
para testes que contemplem também a intervenção humana

  Digo isto não por a apego à Tradição mas sim para evitar
ruído na comunicação depois. Eu simpatizo com o
TDD do Gianni pois me parece que há situações
em que ele é a única alternativa, mas usar o mesmo
nome me parece confuso. 

[Gianni]

Calma! hehe... Acho um pouco precipitado essa conversa. Perfeito seu argumento de não confundir os nomes ou quebrar padrões, etc.

 

Só que eu ainda nem sei se a ideia tem sentido... queria antes propor o abandono de tradições, dogmas e etc para nos dar liberdade de pensar. Ao fim desse exercício vamos ver se sobre algo que vale a pena. Daí a gente dá um nome.

 

O problema de dar um nome agora, é já supor que é a resposta (TDD 2.0 ou algo assim). Quem sabe a resposta é outra? TDD tradicional + testes contínuos. O TDD moldca o desenvolvimento (daí o Driven), os testes contínuos só ajudam a validar, e não guiam o desenvolvimento... Quem sabe não, quem sabe realmente vira um TDD 2.0....

[Walter Mascarenhas]

  Pois é, até as metodologias de teste precisam ser testadas...

[André Luis Pereira]

Pensei esse final de semana sobre esse assunto e ainda não achei uma boa maneira de traduzir isso tudo em alguma coisa mais elaborada, tal como uma real metodologia.

Mas como fiquei bastante curioso em testar algo, alguém tem alguma sugestão de cola entre TDD e testes manuais de maneira mais integrada?

Sei que eu poderia jogar os testes manuais para a fase dos testes de aceitação ou para os testes de integração, mas fiquei curioso para uma integração mais próxima que isso, já que do contrário, não haveria nada de novidade.

-----------------------------------------------------------
   André Luis Pereira

Grupo BSR Participações LTDA
BSRSoft LTDA
an...@bsrpar.com

Site: http://soft.bsrpar.com

Blogs pessoais:

Meus Objetos são QT (programação/desenvolvimento):   http://meusobjetossaoqt.blogspot.com.br

Nossos Prazeres (gastronomia/enologia/cervejas):   http://nossosprazeres.blogspot.com.br

Livro: FreeBSD: Servidores de Alta Performance - Configurações simples e rápidas:  https://www.clubedeautores.com.br/book/141871--FreeBSD_Servidores_de_Alta_Performance

"Vai imprimir este email? Pense antes em sua responsabilidade com a
preservação do meio-ambiente e com a redução de seus custos."

--------------------------------------------------------------
"Uma corrente é tão segura quanto seu elo mais fraco"
---------------------------------------------------------------

--

[Gianni]

Pensei em algumas coisas também. Ao contrário de testes de aceitação ou etc,
os testes com IH (intervenção humana) usados em TDD deveriam:

1 - Ser TODOS binários. Algo acontece (toca um som) e o programa faz um
pergunta ao usuário verdadeiro/falso. Testes de IH nunca podem ser
subjetivos.

2 - A resposta pedida ao usuário deve ser sempre de duas opções, entradas pelo
teclado, usando teclas aleatórias. Tipo:
Ouviu o som? Tecle '5' p/ sim, 'a' p/ não.
Cada vez que o teste for rodado estas teclas devem mudar. Assim, o usuário é
forçado a pensar, e não só teclar sempre a mesma coisa. A pergunta porém,
nunca pode mudar. Isso poderia confundir e se digitar o oposto do desejado.

> > **

> > --~ [&] C & C++ Brasil - http://www.ccppbrasil.org/

[André Luis Pereira]

Em 1 de abril de 2013 07:29, Gianni <nasus....@gmail.com> escreveu:

Pensei em algumas coisas também.  Ao contrário de testes de aceitação ou etc,
os testes com IH (intervenção humana) usados em TDD deveriam:

1 - Ser TODOS binários.  Algo acontece (toca um som) e o programa faz um
pergunta ao usuário verdadeiro/falso.  Testes de IH nunca podem ser
subjetivos.

2 - A resposta pedida ao usuário deve ser sempre de duas opções, entradas pelo
teclado, usando teclas aleatórias.  Tipo:
Ouviu o som?  Tecle '5' p/ sim, 'a' p/ não.
Cada vez que o teste for rodado estas teclas devem mudar.  Assim, o usuário é
forçado a pensar, e não só teclar sempre a mesma coisa.  A pergunta porém,
nunca pode mudar.  Isso poderia confundir e se digitar o oposto do desejado.

Isso se parece com uma suite de testes de linha de produção de hardware.

Não existe nada assim já pronto para testar em C++ ou C?

Isso, se puder ser integrado junto com os outros testes unitários normais, tanto em TDD quanto sem o TDD, poderia funcionar sem problemas e trazer muitos ganhos, creio eu.

-----------------------------------------------------------
   André Luis Pereira

Grupo BSR Participações LTDA
an...@bsrpar.com

Site: http://soft.bsrpar.com

Blogs pessoais:

Meus Objetos são QT (programação/desenvolvimento):   http://meusobjetossaoqt.blogspot.com.br

[Gianni]

Na verdade, o legal seria mesmo ter isso integrado. Conversando em PVT com o
Caio a gente teve mais algumas ideias:

1 - Os testes não necessariamente precisam ser binários, mas precisam ter
opções mutuamente exclusivas, e não podem ser nada subjetivas. Sempre só vai
ter 1 opção certa. Se não, um sistema automatizado vai ter dificuldade para
saber se o código está ok ou não.

2 - Deve haver algum sistema que controle a periodicidade com que estes testes
são executados. Como os testes com IH não vai ser executados sempre; não
podemos também deixar de rodar eles totalmente. Algum sistema que por exemplo
rode testes ao se fazer commits no Git, deveria checar se os testes com IH
foram rodados nos últimos X dias, ou Y commits ou algo do tipo. Assim, o
estado do código só pode ser considerado saudável, se todos os testes sem IH
estão passando, e todos os testes com IH passaram pelo menos nos últimos X
dias/Y commits, etc.

3 - Se possível, fazer os testes de IH serem validados por algum H que não foi
o H que fez um commit.

[André Luis Pereira]

Gianni,

Este é um assunto potencialmente interessante no campo do desenvolvimento de novas práticas.

Talvez uma nova metodologia de testes que conseguisse combinar de maneira eficiente automação com testes manuais quando necessários, de maneira o mais integrada possível.

Aliás, a possibilidade de se escrever um bom paper sobre o assunto parece grande.

Alguém tem boas idéias para esta metodologia?

-----------------------------------------------------------
   André Luis Pereira

Grupo BSR Participações LTDA
BSRSoft LTDA
an...@bsrpar.com

+55 (11) 4063 4108

Site: http://soft.bsrpar.com
BSRSoft DIDD: http://didd.bsrpar.com
BSRSoft ServerUX on FreeBSD: http://soft.bsrpar.com/2012/01/o-serverux.html

"Vai imprimir este email? Pense antes em sua responsabilidade com a
preservação do meio-ambiente e com a redução de seus custos."

--------------------------------------------------------------
"Uma corrente é tão segura quanto seu elo mais fraco"
---------------------------------------------------------------

--

[Elias Henrique Ferreira]

Olá André,

Estou acompanhando esta "thread" e imagino que uma boa maneira de implementar testes unitários automatizados seria através de scripts que fariam uma varredura nas classes públicas e construí-se diversas combinações de aplicações em função  da ordem de chamada dos métodos e dos argumentos destes.

Estes testes poderiam verificar automaticamente problemas de "memory leak" ou alocação e desalocação de objetos alem da ordem de chamada dos métodos. 

Mas para que a idéia seja boa ainda falta instruir a estes scripts o que se espera destas aplicações em termos de "negócio".

--
Elias Henrique Ferreira
Automation Engineer

Software Developer
(11)97575-7139 

(13)8835-0474

www.biteiro.com.br
--

2013/3/30 André Luis Pereira <an...@bsrpar.com>

[P.]

Em quarta-feira, 3 de abril de 2013 13h52min30s UTC-3, Elias Henrique escreveu:

 

 

Estou acompanhando esta "thread" e imagino que uma boa maneira de implementar testes unitários automatizados seria através de scripts que fariam uma varredura nas classes públicas e construí-se diversas combinações de aplicações em função  da ordem de chamada dos métodos e dos argumentos destes.

Sempre soa excelente automatizar quando estamos tratando de engenharia, mas os testes -- sua formalização e sua execução -- implicam um pseudo paradoxo da seguinte forma:

Eis um teste que verificou se a máquina está boa ou não.
Mas esse teste, ele estava bom ou não?

De modo que escrever um programa gerador de testes do outro programa é, antes de mais nada, escrever um programa.
Esse programa, ele está bom ou não?
Devemos escrever testes para ele?
Ou escrever um programa que gera testes do programa que gera testes?

Eventualmente se torna necessário alcançar algum ponto onde os seres humanos intervém e verificam, com seus próprios olhos, se o bagulho está bom ou não. Este é frequentemente o caso dos testes de unidade -- a garantia de que eles estão bons é o fato de que foram verificados manualmente -- e testes de unidade se prestam muito bem a serem verificados manualmente porque são pequenos, muito pequenos em comparação com a máquina sob teste.

Escrever um programa que gera testes tais que verifiquem se outro programa está correto é um problema quase idêntico ao da análise estática com demonstração de correção.

--
 P.