google test training

Download Google test training

Post on 29-Aug-2014




0 download

Embed Size (px)


Google test training


  • Using the Google unit test framework (aka Google Test) Thierry GAYET
  • PLAN
      • What is an unit test ?
      • Why unit tests?
      • Time for tests?
      • Without adequate tests
      • Time for more features work
      • Small tests, not large tests
      • Why Google test?
      • Features
      • Summary of the gtest usage
      • gTest usage with C++ language
      • gtest usage in C
      • Other projects related
      • Links
      • Questions
  • Introduction
  • Unit Testing definition : A unit test is a test of behaviour (normally functional) whose success or failure is wholly determined by the correctness of the test and the correctness of the unit under test. Thus the unit under test has no external dependencies across boundaries of trust or control, which could introduce other sources of failure. Such external dependencies include networks, databases, files, registries, clocks and user interfaces. What is an unit test ?
    • Support development of Chrome browser
    • Desired feature mix:
      • Portable
      • Extensible
      • Flexible
      • Fast
    • Heritage:
      • xUnit
      • jMock, EasyMock, Hamcrest
    Another testing framework?
    • Initially developed by Google staff
    • Googletest released early 2008
    • Googlemock released early 2009
    • Available on Googlecode
      • Support via mailing list not issue tracker
    • Handover to community during 2010
    Project history
  • Why unit tests?
    • Software evolves.
    • - Requirements change.
    • - Bug fixes
    • - Optimizations
    • - Restructuring for better design
    • Can you confidently make changes?
    • - Must not break existing behaviors.
    • - Must not introduce bugs in new behaviors.
    • - Unlikely to have complete knowledge on the code.
    • Writing automated tests is the only way in which development can scale. It should be MANTDATORY for each delivery (unitary and non-regression tests)!!
  • But I dont have time for tests
      • Maybe you wouldnt be so busy if you had written tests early on.
      • You really cannot afford not writing tests:
        • (Making large changes without tests) is like doing aerial gymnastics without a net. - Michael Feathers, unit tester and author of Working Effectively with Legacy Code
        • Bugs detected later in the development process cost orders of magnitudes more to fix.
          • They reflect in your paycheck!
  • Writing tests = time for more feature work
      • How could this be true?
        • Making code testable often leads to better designs:
          • It forces you to design from the clients perspective.
          • Testable often means nimble and reusable, allowing you to achieve more in less time.
        • If done correctly, tests shouldnt take long to write (and youll get better at it).
          • Test a module in isolation.
          • Small vs large tests
  • Without adequate tests
      • At one point, youll no longer be able to confidently make changes to your project.
      • It will seem that there is never hope to fix all the bugs:
        • One fix creates another bug or two.
        • Have to ship with less critical bugs.
        • Morale is low and people want to leave the team.
      • Does it sounds familiar to you ?
  • Small tests, not large tests
      • Large tests
        • A.k.a system / integration / regression / end-to-end tests
        • Hard to localize error
        • Run slowly
        • How many of you run all your tests before making a check-in?
      • Small tests
        • A.k.a unit tests
        • Test a module / class / function in isolation
        • Run quickly
        • Always run before check-in
      • Large tests are valuable, but most tests should be small tests.
  • Getting back on track
      • Your project suffers from the low-test-coverage syndrome. What should you do?
        • Every change must be accompanied with tests that verify the change.
          • Not just any tests must cover the change
          • No test, no check-in.
          • Test only the delta.
          • Resist the temptation for exceptions.
        • Over time, bring more code under test.
          • When adding to module Foo, might as well add tests for other parts of Foo.
        • Refactor the code along the way.
      • It will not happen over night, but you can do it.
  • Test-driven development (TDD)
      • What it is:
        • Before writing code, write tests : that is very AGILE almost for XP!!
        • Write just enough code to make the tests pass.
        • Refactor to get rid of duplicated code.
        • Repeat.
      • Pros:
        • Think as a client
        • better design
        • Clear metric for progress
        • No more untested code
      • Cons:
        • May interfere with train of thought
      • Should you do it?
        • I dont care about which comes first, as long as the code is properly tested.
  • So, why Google Test?
      • Very portable
      • Easy to learn yet expressive
      • Rich features
        • Add debug info to assertions using /lib/ (0x00e88000)
        • => /lib/tls/i686/cmov/ (0x00673000)
        • /lib/ (0x00d17000)
        • => /lib/ (0x004a3000)
        • And the dependencies of the dynamic gtest library :
        • $ ldd /usr/local/lib/
        • => /usr/lib/ (0x00321000)
        • => /lib/tls/i686/cmov/ (0x00829000)
        • => /lib/tls/i686/cmov/ (0x00994000)
        • => /lib/ (0x00d35000)
        • /lib/ (0x00114000)
        • $ nm gmos_gtest
        • (...)
        • U _ZN7testing14InitGoogleTestEPiPPc
        • 0804eea0 W _ZN7testing15AssertionResultD1Ev
        • U _ZN7testing16AssertionFailureERKNS_7MessageE
        • U _ZN7testing16Ass