Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Code Coverage for Total Security in Application Migrations

179 visualizaciones

Publicado el

So the time has come to take the leap and upgrade your application to a new major version of the underlying framework, or, perhaps, to an entirely different framework... how do you ensure that none of your functionality or usability is impacted by a potentially drastic rewrite of the underlying systems? How can you move forward with 100% confidence in your migrated codebase? Testing, testing and more testing. Using a combination of unit, functional and acceptance tests can give you the certainty you need. In this talk, we will go over key strategies for ensuring that you begin with full code coverage and move forward with confidence.

Publicado en: Ingeniería
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Code Coverage for Total Security in Application Migrations

  1. 1. CODE COVERAGE FOR TOTAL SECURITY IN APPLICATION MIGRATIONS How to prepare for and confirm with confidence that your application is working as intended after a major migration.
  3. 3. WHAT IS ENVISAGE? Envisage International Corporation is an international education marketing company serving students and schools around the world. Our student- focused sites offer relevant information, targeted tools, unique resources and valuable products for international students and educators. ESLdirectory
  4. 4. THE AGE OLD QUESTION…. When do we upgrade?! OMG … PHP7 is OUT!! Did you see the new Bootstrap?! Ooh .. Look a MySQL update! Uh, guys, this site is behind by 2 full Bootstrap versions… Look at all the new features in Yii2! Ugh – have you seen this? It’s still in columnal… Wow, look at these includes…with more includes in them…
  5. 5. THE TIPPING POINT As long as the risks outweigh the rewards, you’ll never upgrade. All things being equal … you probably won’t upgrade. You have to tip the scales. LETS DO IT! Don’t wait until the balance tips because you’ve added ‘threat of impending doom’ to the reward side of the equation! Eh, I don’t know… Risk Reward Increase your reward … or minimize your risk? Which is easier?? Cost
  6. 6. HOW DO WE MAKE IT LESS RISKY? Testing suites with Code Coverage! Our test suites can answer the following questions: How will we make things better? • What was the performance improvement? • What do we tell ‘the boss’ when s/he asks what the potential risks are? Will we BREAK anything? • Infrequently used features? • Custom JavaScript or CSS? • All previous functionality should be present and working as intended!
  7. 7. OK SO WE NEED TO TEST … HOW DO WE DO THAT? Codeception has supported modules for the following frameworks, to name a few, built in: • Symfony • Laravel • WordPress • Joomla • Yii • Zend Framework Codeception Tests with --coverage
  8. 8. WHAT ARE WE GOING TO COVER? • No, not all the things … but close! • 80-100% coverage is the goal!
  9. 9. START WITH A CLEAN SLATE The biggest job is actually going to come *before* you do your migration. Before we upgrade, we need 80-100% Coverage with (ideally) all tests in the Green! Have something you know isn’t working? Document it!
  10. 10. DOWNLOAD CODECEPTION Add the composer requirement, and run composer update (if you do not have Codeception globally installed). ./vendor/bin/yiic webapp ./
  11. 11. INSTALL CODECEPTION> ./vendor/bin/codecept bootstrap Default codeception.yml
  12. 12. SAMPLE CODECEPTION.YML Mileage may vary :p
  13. 13. SAMPLE UNIT.YML FILE Using the modules, this unit test is updated to use the Yii2 module, and enable the orm, email and fixture elements of that model.
  14. 14. SAMPLE FUNCTIONAL.YML FILE For the functional test suite, you will probably need some additional modules and helpers. Ensure that your configuration files are pointing to the proper test server locations.
  15. 15. SAMPLE ACCEPTANCE.YML FILE Using the WebDriver module for the acceptance tests allows us to test the pages with JavaScript enabled. Need help getting your configuration right for your framework? Check the ‘Case Study’ section of the Codeception website for specifics on your framework.
  16. 16. RUN THE SUITE! > ./vendor/bin/codecept run … Meh … but it works! Move the existing PHPUnit tests to the new tests/unit/ folder and try again… > php –S localhost:8080 Make sure your local webserver is running before you try to run the suite!
  17. 17. FIXTURE DATA Your tests are only as good as the data that you’re using! False Sense of Security: • Using ”1” as the ID for everything (No!!) • Checking for a result without checking the details of the result (Also No!!) Use Fixtures specific to your Needs: • Alternate fixtures for detailed scenarios • Fixtures take time to load!! Large fixture data sets should only be included where necessary.
  18. 18. FAKED FIXTURE DATA composer require fzaninotto/faker
  19. 19. ORGANIZE • The @group tag: • Modules • Client/API Systems • Issue based • Filesystem Structure > codecept run --group=EGI-1125 > codecept run --group=newsletter > codecept run --skip-group=api > codecept run unit pax/ > codecept run unit pax/:FindAll
  20. 20. RUN YOUR TEST SUITE WITH COVERAGE >codecept run unit --coverage --coverage-html
  21. 21. DON’T OVERDO IT The @covers tag is a love/hate relationship. 😀😡😭😍
  24. 24. WHAT’S OUR DEV. BOX SETUP? Docker If you’re running in a Docker environment, and you want to test against various versions of PHP or MySQL, then your job is easy! Just swap out your Docker images for PHP or MySQL for the version you want to test. Relaunch your image and run your tests. Virtual Machine If you are using a VM for your testing environment, without Docker, then your upgrade process is going to be a little trickier, and it’s a good idea to get a solid snapshot of your VM state before you start apt-get upgrading your PHP, MySQL or whatever. Dev Machine If your dev machine is your localhost, you don’t really have much room for going backward if things don’t proceed well, unless you’re happy to play with restoring nightly backups. Aaand… go! Whether it’s an apt-get update, a composer update, or whatever the case may be, this is the point at which the actual system migration should occur – then we’re back to testing!
  25. 25. THE UPGRADE / REVIEW LIFECYCLE Refactor/ Update Test Refactor/ Update Test Refactor/ Update Test Upgrade underlying system Test for green!
  26. 26. TEST SUITE STATUS CHECK Errors and Failures? • Cycle back through unit by unit to focus on addressing the issues revealed by the tests. • Leverage the @group tags to narrow your focus down to specific test groups All Green? • Go for the –coverage-html check, and if you’re still all green with 80- 100% coverage, then you can give the green light to releasing the upgrade to production!
  27. 27. 👍 GOOD TO GO! Once all your tests are showing green across the board and coverage is confirmed at 80-100%, you're ready to deploy your upgrade to production and can say with CERTAINTY that your new system is compatible and ready to go! • You’ve had a dry run of the upgrade process • All features are covered and passing: • No nasty surprises at launch. • Everyone goes home on time! • Clients are all happy! (or not, is there such a thing?)
  28. 28. QUESTIONS?
  29. 29. DANA H LUTHER @danaluther