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.

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.
https://joind.in/talk/e386f

2. SR. WEB APPLICATION ARCHITECT
DANA H LUTHER
@danaluther
dluther@envisageinternational.com
https://www.linkedin.com/in/danaluther/

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. 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. 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. 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. 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
http://codeception.com/

8. WHAT ARE WE GOING TO
COVER?
• No, not all the things … but close!
• 80-100% coverage is the goal!

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. DOWNLOAD CODECEPTION
Add the composer requirement, and run composer update (if you do not have Codeception globally
installed).
http://codeception.com/quickstart
./vendor/bin/yiic webapp ./

11. INSTALL CODECEPTION> ./vendor/bin/codecept bootstrap
Default codeception.yml

12. SAMPLE
CODECEPTION.YML
Mileage may vary :p

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. 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. 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.
http://codeception.com/for/yii

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. 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. FAKED FIXTURE DATA https://github.com/fzaninotto/Faker
composer require fzaninotto/faker

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. RUN YOUR TEST SUITE WITH
COVERAGE
>codecept run unit --coverage --coverage-html

21. DON’T OVERDO IT
The @covers tag is a love/hate relationship.
http://codeception.com/docs/11-Codecoverage
😀😡😭😍

22. REVIEW COVERAGE OUTPUT

23. GOT IT ALL COVERED? SWEET, LET’S DO THIS!

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. THE UPGRADE / REVIEW LIFECYCLE
Refactor/
Update
Test
Refactor/
Update
Test
Refactor/
Update
Test
Upgrade
underlying system
Test for green!

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. 👍 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. QUESTIONS?

29. DANA H LUTHER
@danaluther
dluther@envisageinternational.com
https://www.linkedin.com/in/danaluther/
https://joind.in/talk/e386f