Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Testing your code

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.

Testing your code

Unit Testing become Test Driven Development. Introduction to the concept of Unit testing with some examples of PHPUnit. Finishing with a Kata TDD (FizzBuzz). Prepared for a class with 3 hours of duration or 4h repeating the Kata.

Avatar for Alejandro Pérez Batanero

Alejandro Pérez Batanero

March 02, 2015

Other Decks in Programming

Transcript

  1. Problems • We are the worst testing our own code.

    We may forget corner cases. • We test our code as a whole instead of small parts. • To check if everything works fine takes long time, more as the project grows.
  2. Unit test Unit Testing is a method by which individual

    units of source code are tested to determine if they are fit for use. A unit is the smallest testable part of an application - Wikipedia
  3. Why should we unit test? • You can check easily

    if your code works • A unit test is the best updated documentation and guide to understand your code. • We can add new features checking if the old ones still work. • If features break the unit test will tell us where the error is. • Gives us the confidence to refactor code that we don’t know.
  4. How should be a unit test? • Isolated: Not depend

    on other classes. • Repeatable: No side effects • Understable: Clean code your test • Reliable: If something is wrong, must fail
  5. Steps 1. Setup: Get everything you need to test the

    features (instantiate, configurations,...) 2. Run: Execute the System Under Test (SUT) 3. Assertion: Check that your system do what is supposed to do
  6. PHPUnit • Web: https://phpunit.de/ • Installation: https://phpunit.de/manual/current/en/installation.html • Prepare your

    environment for the coming practice • Linux: ◦ wget https://phar.phpunit.de/phpunit.phar ◦ php phpunit.phar --version
  7. Mocks - Doubles • Replace the original class • Avoid

    side effects (database) • Control interactions between classes
  8. What can a method do? • Return a value •

    Modify internal state • Print something • Throw exception • Call other classes
  9. What can a method do? • Return a value •

    Modify internal state • Print something • Throw exception • Call other classes That is not the final behavior
  10. What can a method do? • Return a value •

    Print something • Throw exception • Call other classes Should not
  11. How to test these behaviours? • Return a value •

    Throw exception • Call other classes ➔ Assertions ➔ Assertions ➔ Using doubles
  12. Stub • Return custom results that guide the test •

    Can throw exceptions • Can be called and don’t return anything
  13. My two cents • Simple and easy => Maintainable •

    Testing code is also “Production code” • Test for other developers • SOLIDify your tests • One test => One feature • Use less assertions as possible • Love your tests <3
  14. Test Driven Development 1. Red ◦ Write a failing test.

    Mock all related dependencies. Use baby steps. 2. Implement ◦ Write the minimum code to make the test pass. Don’t make it beautiful, just pass the test. 3. Green ◦ Run the test to check that everything works fine. 4. Refactor (very important) ◦ Now it’s time to make it beautiful, improve your code. This applies to the test itself too.
  15. Kata TDD • Try to resolve a problem in 45

    minutes • Using TDD, so first code your tests • Using pair programming • Make baby steps, from little easy test • Refactor code - Refactor test
  16. Fizz Buzz • Write numbers from 1 to 100 •

    For multiples of 3, print “Fizz” instead of the number • For multiples of 5, print “Buzz” instead of the number • For multiple of 3 and 5 print “FizzBuzz” instead of the number • Ex.: 1, 2, Fizz, 4, Buzz, Fizz, … 13, 14, FizzBuzz, 16 Base environment https://github.com/alexgt9/kata-fizzbuzz