docker.tar.gz

Serve /usercode

Run index.php (quiet composer install)

Serve /usercode (quiet composer install)

execute_apcu

This course is for people who have already learned the basics of PHP (or just finished the "Learn PHP from Scratch" course) and want the bigger picture of making big web applications with this language.

First, you'll learn how all PHP web applications communicate with the world and how to turn multiple source code files into one application. Then you'll learn multiple approaches to structuring the whole application. It will help you write code that's easy to maintain. Also, this is a common topic for job interview questions.

Next, you'll learn different data storage methods, from user sessions to databases. This course doesn't duplicate the official documentation but instead provides an overview of the various tools you can use. You'll learn how to use them in PHP, their tradeoffs, and how to pick what's best for your project.

Finally, you'll learn how to make automated tests for your project to ensure that it works as expected.

Developing Web Applications with PHP

Unit tests are good, but they won't tell us anything if we're misusing the external services. We have **integration tests** to check that.

An external service could mean **anything outside** of our code—an external server providing an API, a database, another application, a command-line tool, or even a different module in our codebase.


## How to write integration tests

In general, integration tests follow the same Arrange-Act-Assert structure, but in this case, the Arrange and Assert phases are trickier. We spawn an instance of an external service to call it. So, we often need to arrange the state of an external system and assert how this state has changed. Since the external system is usually out of our control, we have to do integration-specific tricks to make it work.

If a service is a **data store** or something like a message queue, we can access it to both read and write data. We write the data in the Arrange phase and read it in the Act phase or vice versa. We can access the data store directly in the test or use the service we’re testing for both actions.

For example, let's test a Redis-backed key-value store.

Unit tests are good, but they won't tell us anything if we're misusing the external services. We have **integration tests** to check that.

An external service could mean **anything outside** of our code—an external server providing an API, a database, another application, a command-line tool, or even a different module in our codebase.


# How to write integration tests

In general, integration tests follow the same Arrange-Act-Assert structure, but in this case, the Arrange and Assert phases are trickier. We spawn an instance of an external service to call it. So, we often need to arrange the state of an external system and assert how this state has changed. Since the external system is usually out of our control, we have to do integration-specific tricks to make it work.

If a service is a **data store** or something like a message queue, we can access it to both read and write data. We write the data in the Arrange phase and read it in the Act phase or vice versa. We can access the data store directly in the test or use the service we’re testing for both actions.

For example, let's test a Redis-backed key-value store.

Learn what integration tests are and how to write them. Find out how using fixtures might help you.

Introduction

Communicating with the Client

Static Web Application

Structuring Code Files

Application Architecture Basics

PHP-Based Web Application

Storing State

Databases

Using a Database in the PHP Application

Testing

Testing the PHP Application

Advanced Architecture Patterns

Final Assessment

Conclusion

Integration Testing

How to write integration tests