0

I want to move my application from custom framework to laravel and I try to figure out how I'll provide tests on Laravel in future.

At the moment I test like this:

  • I have my app in 2 folders main and test
    • main folder for appexample.com domain
    • test folder for test.appexample.com domain
  • So when I want to do some changes, firstly I make it in test folder and check if everything works fine, then I copy with replace test folder to main folder

If I would want to use laravel, how should I do those tests correctly with laravel?

Thanks

matiaslauriti
  • 7,065
  • 4
  • 31
  • 43
inGame
  • 17
  • 6
  • if you are going to setup a "test" environment why not bother to setup a "test" database as well? Having the same DB for the test and live environment will only enhance murphy's law – Xiduzo Nov 28 '22 at 20:38
  • ye the "test" database should be too, but question is more about how to correctly test code? should it be 2 laravel projects (one for production and one for test) or its possible to make with 1 laravel project? – inGame Nov 29 '22 at 21:37

1 Answers1

0

So, what you have is not a test environment but a staging environment...

What you would have to have is 2 Laravel apps:

  • Production (appexample.com) should be using a production GIT tag (for example, v1.5.3) or at least use a production branch like master or main
  • Staging (test.exampleapp.com) should be using a development branch like develop or whatever your team defined as it

You can have a look at Laravel Forge and Laravel Envoyer.

  • Forge: Allows you to manage servers, environments, deployments, PHP versions, databases (I do not recommend to have a database on the Laravel app server), and more stuff
    • Those servers can be on AWS, Digital Ocean, and more
  • Envoyer: Allows you to manage deployments, environments, and more
    • The take away from Envoyer is that it will help you deploy easier to multiple servers (let's say you have a load balancer and 4 servers behind it, it will automatically deploy the same code and run deployment steps on each server, and if any fails, it just goes back without the client knowing anything happened)

This means you SHOULD (I would say MUST) have separate databases, one for staging and one for production (YOU NEVER RUN PHPUNIT TEST ON ANY ENVIRONMENT EXCEPT LOCAL OR DEVELOPMENT).

Also, you should "replicate" your data on staging, so staging is as similar as possible related to prouction:

  • Same database version
  • Same web server engine
  • Same PHP version
  • Etc.

If you are going to upgrade any, it is fine if staging has a newer database, web server, PHP, etc. version than production, that is the idea, test stuff there before release.

matiaslauriti
  • 7,065
  • 4
  • 31
  • 43