Test-Driven Development Introduction

  • 1,097 views
Uploaded on

Test-Driven Development에 대한 개략적인 소개를 통해서 업무에 활용한다.

Test-Driven Development에 대한 개략적인 소개를 통해서 업무에 활용한다.

More in: Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,097
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
24
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • TDD promove a criação de código testável. Esta é uma característica importante do código e relaciona-se com: Forte Coesão: Classes coesas -> responsabilidades bem definidas -> testes sintéticos Loose Coupling: Fácil de testar classes isoladamente Baixa redundância: 1 Teste por responsabilidade Encapsulamento: Testes identificam os métodos e propriedades que têm de ser expostos (ajudam a definir a interface) Todas estas características são o resultado de boas práticas de desenvolvimento, pelo que o desenvolvimento de bons testes resulta em melhor código.
  • Um factor que é fácil de observar à medida que ganhamos mais prática a desenvolver código de forma Test-Driven é que é mais simples desenvolver testes para componentes do “interior” do sistema do que para componentes que se encontram na “orla” do sistema. São conhecidas as dificuldades em implementar testes para componentes que lidam com Web Services, Componentes de Acesso a Dados ou interfaces gráficas. Existem algumas técnicas que nos ajudam a lidar com estes desafios.
  • Endo-Testing é uma técnica que consiste em eliminar dependências substituindo objectos dependentes por objectos de teste chamados Mock objects. Mas qual é exactamente a vantagem de criarmos um novo objecto e substituir objectos que fazem parte do domínio por estes objectos de teste? Quando os componentes que pretendemos testar se encontram na “orla” do sistema, as dependências que estes possuem são geralmente de sistemas externos. Por vezes estes sistemas não se encontram disponíveis no ambiente de desenvolvimento ou então produzem resultados não determinísticos. Para termos confiança no resultado dos testes estes têm de ser determinísticos. Nestes casos, os testes devem ser realizados de forma a conseguirmos testar os componentes do sistema isoladamente. Uma solução é utilizar Mock Objects.
  • Imaginemos que tempos uma classe Money com um método estático GetRate() que deve obter uma taxa de câmbio de um Web Service. A questão que se coloca é como é que conseguimos implementar um teste para o método GetRate() da classe Money se o resultado do Web Service é imprevisível (seja porque não está disponível no ambiente de desenvolvimento, ou porque os valores devolvidos pelo Web Service variam constantemente)?
  • A solução consiste em substituir nos testes o proxy do Web Service por um Mock do mesmo. No entanto para conseguirmos criar um Mock Object necessitamos de ter uma interface.
  • Apesar das vantagens, a utilização de Mock Objects apresenta também alguns desafios. Em primeiro lugar, no caso de serem Mock Objects estáticos, resultam em mais classes para manter. No entanto, o maior desafio consiste em como quebrar o encapsulamento de forma a substituir o objecto real pelo Mock.
  • São particularmente difíceis de testar e, consequentemente, difíceis de implementar de forma test-driven. É importante considerar que não basta conseguir definir um teste, é necessário que o próprio processo de implementação do teste e desenvolvimento do código UI correspondente seja simples para que o tempo de turn-around não desencoraje a prática de TDD.

Transcript

  • 1. Test-Driven Development Introduction 김종선 Senior researcher Technology Research Institute
  • 2. Outline
    • What is TDD?
    • TDD in Practice
    • Endo-Testing
    • Test-Driven UI Development
    • Conclusion
  • 3. Test-Driven Development (TDD)
    • Is a programming practice
    • Unit tests are written before the domain code
    • Namely:
      • Write a test that fails
      • Write code to make the test pass
      • Refactor
    • Unit Tests and Refactoring are the tools of TDD
  • 4. Unit Tests
    • Test specific aspects of a functionality
    • Execute rapidly
    • Independent of each other
    • Independent of the surrounding environment
    • Independent of execution order
    • Automated
  • 5. Refactoring
    • Change the internal structure of the code without changing it’s external behavior.
    • Associated with arithmetic factorization:
    • ab + ac = a(b+c)
    • Same result but the expression is simplified.
  • 6. Test List
    • Task Based
      • 4-8 hour duration
      • 15-20 minute exercise at beginning
    • Brainstorm a list of unit tests
    • Do not get hung up on completeness, you can always add more later
    • Describes completion requirements
  • 7. Red / Green / Refactor Write a test for new capability Start Compile Fix compile errors Run the test And see it fail Write the code Run the test And see it pass Refactor as needed
  • 8.
    • Financial Service
      • A simple application that implements the following set of functionality:
        • Credit an Account
        • Debit an Account
  • 9. Characteristics of TDD
    • TDD promotes code testability
    • Testability is related to:
      • Strong cohesion
      • Loose coupling
      • No redundancy
      • Encapsulation
    • These are good programming practices
    • Striving for good tests results in better code
  • 10. TDD Tenets
    • Never write a single line of code unless you have a failing unit test
    • Eliminate Duplication (Refactor mercilessly)
  • 11. Observation
    • It’s harder to write unit tests for components located at the “edge” of the system:
      • Web Services
      • Data Access Layer
      • User Interface
  • 12. Mock Objects
    • Inherent challenges in testing dependant objects
      • Objects dependant on ephemeral objects produce unpredictable behavior
      • User Interfaces, Databases and the like are inherently ephemeral
  • 13. Example
    • How can we write a test for GetRate() when the result of FinancialServicesWS.GetRate() is unpredictable?
    Money +GetRate(string from, string to):double FinancialServices WS +GetRate(string from, string to):double
  • 14. Mock Objects
    • Solution:
      • Replace the unpredictable object with a testing version that produces predictable results
    FinancialServicesWS +GetRate(string from, string to):double MockFinancialServicesWS +GetRate(string from, string to):double IFinancialServicesWS +GetRate(string from, string to):double
  • 15. Conclusion
    • Advantages of Mock Objects:
      • Promote design to interfaces
      • Promote testability and isolation of tests
      • Promote decoupling
    • Challenges of Mock Objects:
      • More classes to maintain
      • Requires breaking encapsulation to replace real object with mock object, sometimes resulting in less “elegant” code
  • 16. User Interfaces
    • Difficult to write automated tests to, because they are designed to be exercised by a user and often hide their programmatic interface.
    • Inherent challenges in testing Windows Forms applications:
      • Are highly coupled
      • .Exe assemblies cannot be referenced from the IDE
  • 17. Conclusion
    • Advantages:
      • Easy to implement
      • Development of UI can be completely test-driven
      • Promotes decoupling
      • Enables creation of automated User Acceptance Tests
    • Challenges:
      • Setup requires somewhat complex wiring
  • 18. References
    • “ Test-Driven Development By Example”, Kent Beck
    • “ Refactoring, Improving The Design Of Existing Code”, Martin Fowler
    • “ Patterns Of Enterprise Application Architecture”, Martin Fowler
  • 19. Q & A