Unit Testing
A (not so) short introduction

Company

LOGO
Alejandro Claro Mosqueda
What is all this stuff?!

AAA
QA key questions

Business Facing

Are we building the right product?

Are we building the product right?
Technology/Imple...
Accidental
Defects?

Essential
Defects?

Quality Assurance is more than look for bugs!

Critique Product

Supporting the t...
Brian Marick’s test categorization
Test size classification
Ok! But what is a unit test?
A unit test is an automated piece of code that invokes the method being
tested and then check...
What are they good for?
 Unit tests prove that your code actually works (at a function/method level).
 You get some kind...
What are they not for?
 It's not for testing correct inter-operation of multiple subsystems.
 It should be a stand-alone...
Disadvantages
 Big time investment.

For the simple case you lose about 20% of the actual implementation, but for
complic...
Best Practices!
 Make sure your tests test one thing and one thing only.
 Each unit test should be independent from the ...
Isolate!
State testing asserts properties on an object.
Interaction testing is testing how an object sends input to or rec...
Naming by Unit Of Work

MethodUnderTest_Input_ExpectedOutput
MethodUnderTest_LogicalAction_ExpectedChangeInBehavior
Method...
Arrange-Act-Assert (AAA) Pattern
Arrange: setup everything needed for the running the tested code. This includes any
initi...
Bad Practices and anti-patterns
 Static methods. Static methods are death to unit testability because they cannot
be mock...
Test fixture (Harness)
Test fixture refers to the fixed state used as a baseline for running tests. The
purpose of a test ...
Test fixture process
When do you write the test?

After/During coding
 Focus on code.
 Thinking about algorithm.

 More refactoring.
 Easie...
When do you write the test?

Before coding (TDD, BDD)
 Focus on requirements.

 Thinking about how code will be
consumed...
Test driven development (TDD)
“TDD is a design process, not a testing process.”
Acceptance vs Unit testing
ATs and UTs are the same though, right?
 Both can be written before implementation.
 Both sho...
Black-box and White-box testing
Careful - They are NOT the same!
Acceptance test is owned and defined by the customer to verify that a
story is complete a...
Acceptance and Unit testing relation

setup

ATD

AT
impl
teardown
setup

ATD

AT
impl

Application Interface

Test
Implem...
Acceptance Test Driven Development (ATDD)
Let’s talk!
Motivation is what gets you starting; practice is what
keeps you going
Upcoming SlideShare
Loading in …5
×

Unit testing - An introduction

801 views

Published on

A brief introduction to software unit testing.

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
801
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Unit testing - An introduction

  1. 1. Unit Testing A (not so) short introduction Company LOGO Alejandro Claro Mosqueda
  2. 2. What is all this stuff?! AAA
  3. 3. QA key questions Business Facing Are we building the right product? Are we building the product right? Technology/Implementation Facing Quality Assurance is more than look for bugs!
  4. 4. Accidental Defects? Essential Defects? Quality Assurance is more than look for bugs! Critique Product Supporting the team QA key questions
  5. 5. Brian Marick’s test categorization
  6. 6. Test size classification
  7. 7. Ok! But what is a unit test? A unit test is an automated piece of code that invokes the method being tested and then checks some assumptions about the logical behavior of that method. It can be written easily and runs quickly. It’s fully automated, trustworthy, readable, isolated, and maintainable.
  8. 8. What are they good for?  Unit tests prove that your code actually works (at a function/method level).  You get some kind of “low-level regression-test” suite.  You can improve the design without breaking it.  They demonstrate concrete progress.  Unit tests are a form of sample code.  It forces you to plan before you code.  It reduces the cost of bugs.  It's even better than code inspections.
  9. 9. What are they not for?  It's not for testing correct inter-operation of multiple subsystems.  It should be a stand-alone test which is not related to other subsystems.  Test against external resources (data base, LDAP, third party libraries, etc).  Introducing dependencies on external resources or data turns unit tests into integration tests.  In many cases you can't write a unit test to reproduce bug appeared in production.  It's not regression testing.
  10. 10. Disadvantages  Big time investment. For the simple case you lose about 20% of the actual implementation, but for complicated cases you lose much more.  Design Impacts. Sometimes the high-level design is not clear at the start and evolves as you go along - this will force you to completely redo your test which will generate a big time lose.
  11. 11. Best Practices!  Make sure your tests test one thing and one thing only.  Each unit test should be independent from the other.  Keep consistent conventions (e.g. AAA). Readability is important for tests.  Name your unit tests clearly and consistently.  Separate you concerns. Extract layers to improve the design.  Avoid unnecessary preconditions.  Fake behavior with mocks or stubs to concentrate on test scenario.  Check code coverage during testing.  Don’t unit-test configuration settings.  Tests should run automatically to provide continuous feedback. Keep the bar green to keep the code clean!
  12. 12. Isolate! State testing asserts properties on an object. Interaction testing is testing how an object sends input to or receives input from other objects — how that object interacts with other objects. Stub is a controllable replacement for an existing dependency in the system. By using a stub, you can test your code without dealing with the dependency directly. Mock object is a fake object in the system that decides whether the unit test has passed or failed. It does so by verifying whether the object under test interacted as expected with the fake object.
  13. 13. Naming by Unit Of Work MethodUnderTest_Input_ExpectedOutput MethodUnderTest_LogicalAction_ExpectedChangeInBehavior MethodUnderTest_ActionOrInput_ExepectedCallToThirdParty Addition_PositiveNumbers_ReturnsSum() Addition_WhenCalled_ResetsTheNextSum() Addition_NegativeNumbers_CallsLogger()
  14. 14. Arrange-Act-Assert (AAA) Pattern Arrange: setup everything needed for the running the tested code. This includes any initialization of dependencies, mocks and data needed for the test to run. Act: Invoke the code under test. Assert: Specify the pass criteria for the test, which fails it if not met.
  15. 15. Bad Practices and anti-patterns  Static methods. Static methods are death to unit testability because they cannot be mocked or stubbed.  Relying on external resources.  Unit test for GUI.  Constrained test order.  Hidden test call.  Mutable shared-state.  Multiple asserts.
  16. 16. Test fixture (Harness) Test fixture refers to the fixed state used as a baseline for running tests. The purpose of a test fixture is to ensure that there is a well known and fixed environment in which tests are run so that results are repeatable.
  17. 17. Test fixture process
  18. 18. When do you write the test? After/During coding  Focus on code.  Thinking about algorithm.  More refactoring.  Easier initially.
  19. 19. When do you write the test? Before coding (TDD, BDD)  Focus on requirements.  Thinking about how code will be consumed.  Stop coding when reqs met.  Harder initially.
  20. 20. Test driven development (TDD) “TDD is a design process, not a testing process.”
  21. 21. Acceptance vs Unit testing ATs and UTs are the same though, right?  Both can be written before implementation.  Both should be automated by containing assertions for validating expected results.  Both typically use fixture setup and teardown code to run before and after the execution of the tests.  Both can be implemented using a framework.
  22. 22. Black-box and White-box testing
  23. 23. Careful - They are NOT the same! Acceptance test is owned and defined by the customer to verify that a story is complete and correct.  ATs must be defined in a language familiar to the customer:  Generic enough to capture requirements  Abstract enough to be maintainable  Simple enough to be easily understood  ATs should be defined and run using a tool accessible to the customer.  ATs encourage the customer to consider the all aspects of user experience.  ATs test interaction of all layers in the system.  ATs require external systems to be operating correctly.
  24. 24. Acceptance and Unit testing relation setup ATD AT impl teardown setup ATD AT impl Application Interface Test Implementation Acceptance Test Client Acceptance Test Definition Units Implementation Unit Test Fixture Setup impl UT impl impl UT UT impl teardown UT setup ATD impl AT impl UT impl UT teardown Mock Teardown
  25. 25. Acceptance Test Driven Development (ATDD)
  26. 26. Let’s talk! Motivation is what gets you starting; practice is what keeps you going

×