Development/Tutorials/Unittests (pt BR) - Revision history

AnneW at 16:54, 19 July 2012

2012-07-19T16:54:02Z

Neverendingo: Text replace - "" to ""

2011-06-29T20:56:37Z

Text replace - "</code>" to "</syntaxhighlight>"

Neverendingo: Text replace - "`" to ""`


2011-06-29T20:46:13Z
Text replace - "<code>" to "<syntaxhighlight lang="text">"

				
				
				
				
			
			← Older revision
			Revision as of 20:46, 29 June 2011
			
Line 88:
Line 88:
    
  '''Example 2. QDate unit test project'''   '''Example 2. QDate unit test project'''
− <code> + <syntaxhighlight lang="text">
  CONFIG += qtestlib   CONFIG += qtestlib
  TEMPLATE = app   TEMPLATE = app
Line 100:
Line 100:
  Save as tutorial1.pro   Save as tutorial1.pro
    
− This is a fairly normal project file, except for the addition of the <code>CONFIG += qtestlib</code>. This adds the right header and library setup to the Makefile.   + This is a fairly normal project file, except for the addition of the <syntaxhighlight lang="text">CONFIG += qtestlib</code>. This adds the right header and library setup to the Makefile.  
    
− Create an empty file called tutorial1.h and compile with <code>qmake; make</code> The output looks like the following: + Create an empty file called tutorial1.h and compile with <syntaxhighlight lang="text">qmake; make</code> The output looks like the following:
    
  '''Example 3. QDate unit test output'''   '''Example 3. QDate unit test output'''
− <code> + <syntaxhighlight lang="text">
  $ ./tutorial1   $ ./tutorial1
  ********* Start testing of testDate *********   ********* Start testing of testDate *********
Line 124:
Line 124:
    
  '''Example 4. QDate unit test output showing failure'''   '''Example 4. QDate unit test output showing failure'''
− <code> + <syntaxhighlight lang="text">
  $ ./tutorial1   $ ./tutorial1
  ********* Start testing of testDate *********   ********* Start testing of testDate *********
Line 145:
Line 145:
  '''Example 5. QDate unit test output - selected function'''   '''Example 5. QDate unit test output - selected function'''
    
− <code> + <syntaxhighlight lang="text">
  $ ./tutorial1 testValidity   $ ./tutorial1 testValidity
  ********* Start testing of testDate *********   ********* Start testing of testDate *********
Line 161:
Line 161:
    
  '''Example 6. QDate unit test output - listing functions'''   '''Example 6. QDate unit test output - listing functions'''
− <code> + <syntaxhighlight lang="text">
  $ ./tutorial1 -functions   $ ./tutorial1 -functions
  testValidity()   testValidity()
Line 173:
Line 173:
  '''Example 7. QDate unit test output - verbose output'''   '''Example 7. QDate unit test output - verbose output'''
    
− <code> + <syntaxhighlight lang="text">
  $ ./tutorial1 -v1   $ ./tutorial1 -v1
  ********* Start testing of testDate *********   ********* Start testing of testDate *********
Line 193:
Line 193:
  ''''Example 8. QDate unit test output - more verbose output'''   ''''Example 8. QDate unit test output - more verbose output'''
    
− <code> + <syntaxhighlight lang="text">
  $ ./tutorial1 -v2   $ ./tutorial1 -v2
  ********* Start testing of testDate *********   ********* Start testing of testDate *********
Line 289:
Line 289:
  '''Example 10. Results of data driven testing, showing QFETCH'''   '''Example 10. Results of data driven testing, showing QFETCH'''
    
− <code> + <syntaxhighlight lang="text">
  $ ./tutorial2 -v2   $ ./tutorial2 -v2
  ********* Start testing of testDate *********   ********* Start testing of testDate *********
Line 348:
Line 348:
    
  '''Example 12. QDate unit test output - selected function and data'''   '''Example 12. QDate unit test output - selected function and data'''
− <code> + <syntaxhighlight lang="text">
  $ ./tutorial2 -v2 testMonth:1967/3/11   $ ./tutorial2 -v2 testMonth:1967/3/11
  ********* Start testing of testDate *********   ********* Start testing of testDate *********
Line 620:
Line 620:
    
  '''Example 15. Unit test showing skipped tests'''   '''Example 15. Unit test showing skipped tests'''
− <code> + <syntaxhighlight lang="text">
  void testDate::testSkip_data()   void testDate::testSkip_data()
  {   {
Line 647:
Line 647:
    
  '''Example 16. Output of unit test showing skipped tests'''   '''Example 16. Output of unit test showing skipped tests'''
− <code> + <syntaxhighlight lang="text">
  $ ./tutorial4 testSkip -v2   $ ./tutorial4 testSkip -v2
  ********* Start testing of testDate *********   ********* Start testing of testDate *********
Line 695:
Line 695:
  '''Example 18. Output of unit test showing expected failures'''   '''Example 18. Output of unit test showing expected failures'''
    
− <code> + <syntaxhighlight lang="text">
  $ ./tutorial4/tutorial4 testExpectedFail -v2   $ ./tutorial4/tutorial4 testExpectedFail -v2
  ********* Start testing of testDate *********   ********* Start testing of testDate *********
Line 745:
Line 745:
  '''Example 20. Output of unit test showing unexpected pass'''   '''Example 20. Output of unit test showing unexpected pass'''
    
− <code> + <syntaxhighlight lang="text">
  $ ./tutorial4/tutorial4 testUnexpectedPass -v2   $ ./tutorial4/tutorial4 testUnexpectedPass -v2
  ********* Start testing of testDate *********   ********* Start testing of testDate *********
Line 785:
Line 785:
    
  '''Example 22. Output of unit test producing warning and debug messages'''   '''Example 22. Output of unit test producing warning and debug messages'''
− <code> + <syntaxhighlight lang="text">
  $ ./tutorial4 testQdebug   $ ./tutorial4 testQdebug
  ********* Start testing of testDate *********   ********* Start testing of testDate *********
Line 824:
Line 824:
                         
  '''Example 24. Output of ignoreMessage example'''   '''Example 24. Output of ignoreMessage example'''
− <code> + <syntaxhighlight lang="text">
  $ ./tutorial4 testValidity testValiditi   $ ./tutorial4 testValidity testValiditi
  ********* Start testing of testDate *********   ********* Start testing of testDate *********
Line 1,028:
Line 1,028:
  If you are working in a KDE4 environment, then it is pretty easy to get CMake set up to build and run a test on demand.   If you are working in a KDE4 environment, then it is pretty easy to get CMake set up to build and run a test on demand.
    
− <code> + <syntaxhighlight lang="text">
  set( kwhatevertest_SRCS kwhatevertest.cpp )   set( kwhatevertest_SRCS kwhatevertest.cpp )



Neverendingo: Text replace - "" to ""

2011-06-29T20:32:40Z
Text replace - "<code cppqt n>" to "<syntaxhighlight lang="cpp-qt" line>"

				
				
				
				
			
			← Older revision
			Revision as of 20:32, 29 June 2011
			
Line 36:
Line 36:
    
  '''Example 1. QDate test code'''   '''Example 1. QDate test code'''
− <code cppqt n> + <syntaxhighlight lang="cpp-qt" line>
  #include <QtTest>   #include <QtTest>
  #include <QtCore>   #include <QtCore>
Line 228:
Line 228:
    
  '''Example 9. QDate test code, data driven version'''   '''Example 9. QDate test code, data driven version'''
− <code cppqt n> + <syntaxhighlight lang="cpp-qt" line>
  #include <QtTest>   #include <QtTest>
  #include <QtCore>   #include <QtCore>
Line 325:
Line 325:
  '''Example 11. QDate test code, data driven version using QTEST'''   '''Example 11. QDate test code, data driven version using QTEST'''
    
− <code cppqt n> + <syntaxhighlight lang="cpp-qt" line>
  void testDate::testMonth()   void testDate::testMonth()
  {   {
Line 380:
Line 380:
  '''Example 13. QDateEdit test code'''   '''Example 13. QDateEdit test code'''
    
− <code cppqt n> + <syntaxhighlight lang="cpp-qt" line>
  #include <QtTest>   #include <QtTest>
  #include <QtCore>   #include <QtCore>
Line 505:
Line 505:
    
  '''Example 14. QDateEdit test code, using QTestEventList'''   '''Example 14. QDateEdit test code, using QTestEventList'''
− <code cppqt n>         + <syntaxhighlight lang="cpp-qt" line>        
  #include <QtTest>   #include <QtTest>
  #include <QtCore>   #include <QtCore>
Line 679:
Line 679:
  '''Example 17. Unit test showing expected failures'''   '''Example 17. Unit test showing expected failures'''
    
− <code cppqt n> + <syntaxhighlight lang="cpp-qt" line>
  void testDate::testExpectedFail()   void testDate::testExpectedFail()
  {   {
Line 730:
Line 730:
    
  '''Example 19. Unit test showing unexpected pass'''   '''Example 19. Unit test showing unexpected pass'''
− <code cppqt n> + <syntaxhighlight lang="cpp-qt" line>
  void testDate::testUnexpectedPass()   void testDate::testUnexpectedPass()
  {   {
Line 775:
Line 775:
    
  Example 21. Unit test producing warning and debug messages   Example 21. Unit test producing warning and debug messages
− <code cppqt n> + <syntaxhighlight lang="cpp-qt" line>
  void testDate::testQdebug()   void testDate::testQdebug()
  {   {
Line 808:
Line 808:
    
  '''Example 23. Example of using ignoreMessage'''   '''Example 23. Example of using ignoreMessage'''
− <code cppqt n> + <syntaxhighlight lang="cpp-qt" line>
  void testDate::testValidity()   void testDate::testValidity()
  {   {
Line 853:
Line 853:
    
  '''Example 25. QLabel test code, showing testing of a couple of slots'''   '''Example 25. QLabel test code, showing testing of a couple of slots'''
− <code cppqt n> + <syntaxhighlight lang="cpp-qt" line>
  #include <QtTest>   #include <QtTest>
  #include <QtCore>   #include <QtCore>
Line 892:
Line 892:
  '''Example 26. QCheckBox test code, showing testing of signals'''   '''Example 26. QCheckBox test code, showing testing of signals'''
    
− <code cppqt n> + <syntaxhighlight lang="cpp-qt" line>
  #include <QtTest>   #include <QtTest>
  #include <QtCore>   #include <QtCore>



Camilasan at 17:13, 26 March 2011
2011-03-26T17:13:02Z


				
				
				
				
			
			← Older revision
			Revision as of 17:13, 26 March 2011
			
Line 6:
Line 6:
    
  Esse artigo é um guia para escrever testes unitários para Qt4 e KDE4, baseado no [http://doc.qt.nokia.com/latest/qtestlib-manual.html framework QtTestLib] lançado no Qt 4.1. Esse provê uma introdução para as idéias por trás de testes unitários, tutorial sobre [http://doc.qt.nokia.com/latest/qtestlib-manual.html framework QtTestLib] e sugestões para obter um resultado melhor nos testes. Esse documento está de acordo com o Qt4.1 e KDE4.   Esse artigo é um guia para escrever testes unitários para Qt4 e KDE4, baseado no [http://doc.qt.nokia.com/latest/qtestlib-manual.html framework QtTestLib] lançado no Qt 4.1. Esse provê uma introdução para as idéias por trás de testes unitários, tutorial sobre [http://doc.qt.nokia.com/latest/qtestlib-manual.html framework QtTestLib] e sugestões para obter um resultado melhor nos testes. Esse documento está de acordo com o Qt4.1 e KDE4.
−  
    
  == Sobre Testes Unitários ==   == Sobre Testes Unitários ==
Line 14:
Line 13:
  Testes unitários são a parte principal do TDD (Desenvolvimento Orientado/Dirigido a Testes), de qualquer forma eles são úteis para todos os processos de desenvolvimento de software. Não é necessário que todo o código tenha cobertura de testes unitários (embora isso seja desejável!). Mesmo um único teste é passo útil para aumentar a qualidade do código.   Testes unitários são a parte principal do TDD (Desenvolvimento Orientado/Dirigido a Testes), de qualquer forma eles são úteis para todos os processos de desenvolvimento de software. Não é necessário que todo o código tenha cobertura de testes unitários (embora isso seja desejável!). Mesmo um único teste é passo útil para aumentar a qualidade do código.
    
− Note that unit tests are dynamic tests (i.e. they run, using the compiled code) rather than static analysis tests (which operate on the source or some intermediate representation). + Note que testes unitários são testes dinâmicos (eles rodam usando o código compilado) melhor que testes de análise estática (que age no código fonte ou em uma representação intermediária disso).
−   + 
− Even if they don't call them "unit tests", most programmers have written some "throwaway" code that they use to check an implementation. If that code was cleaned up a little, and built into the development system, then it could be used over and over to check that the implementation is still OK. To make that work a little easier, we can use test frameworks.   + 
    
− Note that it is sometimes tempting to treat the unit test as a pure verification tool. While it is true that unit tests do help to ensure correct functionality and behaviour, they also assist with other aspects of code quality. Writing a unit test requires a slightly different approach to coding up a class, and thinking about what inputs need to be tested can help to identify logic flaws in the code (even before the tests get run). In addition, the need to make the code testable is a very useful driver to ensure that classes do not suffer from close coupling.   + Mesmo se não são chamados "testes unitários", a maioria dos programadores tem escrito algum código "descartável" que eles usam para verificar uma implementação. Se esse código foi um pouco limpo, e desenvolvido em um sistema de desenvolvimento, então poderia ser usado várias vezes para verificar se a implementação ainda está funcionando. Para fazer isso um pouco mais fácil, nós podemos usar frameworks de teste.
    
− Anyway, enough of the conceptual stuff - lets talk about a specific tool that can reduce some of the effort and let us get on with the job. + Note que algumas vezes isso é uma tentação para tratar o teste unitário puramente como uma ferramenta de verificação. Enquanto é verdade que testes unitários ajudam e muito a garantir correta funcionalidade e comportamento, eles também  contribuem com outros aspectos da qualidade do código, e pensando sobre que inputs precisam ser testados podem ajudar a identificar problemas de lógica no código (mesmo antes de rodar os testes). Em adição, o necessário para fazer o código estável é guia muito útil para garantir que classes não sofram de close coupling.
    
− ==About QtTestLib== + Depois de muitos conceitos - vamos falar sobre uma ferramenta específica que ode reduzir algum esforços e deixar nós chegarmos no trabalho propriamente dito.
    
− QtTestlib is a lightweight testing library developed by Trolltech and released under the GPL (a commercial version is also available, for those who need alternative licensing). It is written in C++, and is cross-platform. It is provided as part of the tools included in Qt 4.1, and earlier versions were provided separately. Note that earlier versions had a different API, and the examples will not work with that earlier version. + == Sobre QtTestLib==
    
− In addition to normal unit testing capabilities, QtTestLib also offers basic GUI testing, based on sending QEvents. This allows you to test GUI widgets, but is not generally suitable for testing full applications.   + QtTestLib é uma biblioteca de testes leve desenvolvida pela TrollTech e lançada sobre a lincença GPL (uma versão comercial está disponível também, mas é necessário uma licença diferente). É escrito em C++ e é multiplataforma. Faz parte do Qt 4.1 e antes disso, foram lançadas versão separadamente. Versões antigas tem uma API diferente e os exemplos não vão funcionar com versões antigas.  
    
− Each testcase is a standalone test application. Unlike CppUnit or JUnit, there is no Runner type class. Instead, each testcase is an executable which is simply run. + Em adição a capacidade dos testes unitários, QtTestLib também oferece testes básicos de interface, baseados em QEvents. Isso te permite testar GUI widgets, mas não é geralmente indicado para testar uma aplicação inteira.
    
− == Tutorial 1: A simple test of a date class == + Cada testcase é um aplicção de teste independente. Diferente de CppUnit ou JUnit, não há uma classe tipo Runner. Ao invés, cada testcase é um executável que é só rodar.
    
− In this tutorial, we will build a simple test for a class that represents a date, using QtTestLib as the test framework. To avoid too much detail on how the date class works, we'll just use the  QDate. class that comes with Qt. In a normal unittest, you would more likely be testing code that you've written yourself. + == Tutorial 1: Um simples teste de uma classe Data ==
    
− The code below is the entire testcase. + Neste tutorial, nós vamos construir um teste simples para uma classe que representa uma data, usando QtTestLib como framework de teste. Para evitar muitos detalhes de como a classe data funciona, nós vamos usar apenas QDate. Classe que vem com o Qt. Em um teste unitário normal, você provavelmente testaria código escrito por você mesmo.  
    
  + O código abaixo é um testecase completo.
    
  '''Example 1. QDate test code'''   '''Example 1. QDate test code'''



Camilasan at 17:02, 26 March 2011
2011-03-26T17:02:19Z


				
				
				
				
			
			← Older revision
			Revision as of 17:02, 26 March 2011
			
Line 5:
Line 5:
  == Abstract ==   == Abstract ==
    
− This article provides guidance on writing unittests for Qt4 and KDE4, based on the QtTestLib framework provided starting with Qt4.1. It provides an introduction to the ideas behind unit testing, tutorial material on the [http://doc.qt.nokia.com/latest/qtestlib-manual.html QtTestLib framework], and suggestions for getting the most value for your effort.   + Esse artigo é um guia para escrever testes unitários para Qt4 e KDE4, baseado no [http://doc.qt.nokia.com/latest/qtestlib-manual.html framework QtTestLib] lançado no Qt 4.1. Esse provê uma introdução para as idéias por trás de testes unitários, tutorial sobre [http://doc.qt.nokia.com/latest/qtestlib-manual.html framework QtTestLib] e sugestões para obter um resultado melhor nos testes. Esse documento está de acordo com o Qt4.1 e KDE4.
− This document is matched to Qt 4.1 and KDE 4. + 
    
− == About Unit Testing ==  
    
− A unit test is a test that checks the functionality, behaviour and correctness of a single software component. In Qt4 code (including KDE4 code) unit tests are almost always used to test a single C++ class (although testing a macro or C function is also possible). + == Sobre Testes Unitários ==
    
− Unit tests are a key part of Test Driven Development, however they are useful for all software development processes. It is not essential that all of the code is covered by unit tests (although that is obviously very desirable!). Even a single test is a useful step to improving code quality.   + Testes unitários verificam a funcionalidade, comportamento e conformidade de um componente do software. No Qt4 (incluindo KDE4) testes unitários são quase sempre usados para testar uma única classe C++ (embora testar uma macro ou função C é possível também).
  +  
  + Testes unitários são a parte principal do TDD (Desenvolvimento Orientado/Dirigido a Testes), de qualquer forma eles são úteis para todos os processos de desenvolvimento de software. Não é necessário que todo o código tenha cobertura de testes unitários (embora isso seja desejável!). Mesmo um único teste é passo útil para aumentar a qualidade do código.
    
  Note that unit tests are dynamic tests (i.e. they run, using the compiled code) rather than static analysis tests (which operate on the source or some intermediate representation).     Note that unit tests are dynamic tests (i.e. they run, using the compiled code) rather than static analysis tests (which operate on the source or some intermediate representation).  



Camilasan: Created page with '{{Template:I18n/Language Navigation Bar|Development/Tutorials/Unittests}}  '''Author:''' Brad Hards, Sigma Bravo Pty Limited  == Abstract ==  This article provides guidance on wr...'
2011-03-26T14:50:05Z
Created page with '{{Template:I18n/Language Navigation Bar|Development/Tutorials/Unittests}}  '''Author:''' Brad Hards, Sigma Bravo Pty Limited  == Abstract ==  This article provides guidance on wr...'
Show changes

← Older revision		Revision as of 16:54, 19 July 2012
Line 1:		Line 1:
−	~~{{Template:I18n/Language Navigation Bar\|Development/Tutorials/Unittests}}~~	+

	'''Author:''' Brad Hards, Sigma Bravo Pty Limited		'''Author:''' Brad Hards, Sigma Bravo Pty Limited