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

Testing your code

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.

Alejandro Pérez Batanero

March 02, 2015
Tweet

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