How to properly test a website?



  • Given: Laravel, admin + rest api, postgreSQL, phpunit. Functionality: articles with pictures.

    How to properly unit / feature testing?

    I have the following Questions:

    • Test service and repository separately?
    • Should I use some other database for testing? So I will not break the filled working database.
    • How to test the functionality of loading images? And in general, where to upload them, in the same folder as when working on production, or create a separate folder?
    • Do I need to somehow differentiate the prod / dev config for testing? Or is it possible to somehow change the config when unit testing using phpunit?


    1. Test together

    2. You can use another database, but completely authentic (and who prevents you from making a full backup of everything before testing, and saving in a couple of copies, as a reference - in the case of yours?)

    3. Everything needs to be done, as close as possible to production - if changing the folder is not critical, then you can.

    4. Test a small block of the entire testing spectrum (some data) in both modes and see the difference - if they are not essential, then on dev it is quite possible. Of course, for the purity of the experiment, there is always a puddle of production - but look at the expediency and take the necessary parameters.

    In general, the closer you are to production, the better, you need to move away from this only in unavoidable cases. The results of such a test can not only serve as an argument, but also protect the developer - in case something comes out after, if suddenly - everything happens in life, but after such a test (production) it is impossible to foresee everything, and of course, it is difficult to suspect the development in which something manipulation.



  • At some point in their lives, projects begin to require support and testing. To do this, in most cases, they come to the distribution of assemblies on dev - stage - prod, where each element is a polygon with its own version of the code.

    dev: developer's unstable polygon, for development. Errors, temporary offline, manual edits and so on are allowed.
    stage: pre-prod polygon, for testing and error detection. Errors allowed, offline not allowed, fully automated roll-out using CI.
    prod: "battle" polygon. Users come here. Its fall and found bugs are the reason for the decrease in bonuses for programmers / testers / devops.
    Accordingly, each polygon has its own database, its own environment, and so on. Typically, this is a collection of separate virtual machines. There can be several polygons of each type, depending on the goals, it is allowed to raise a sub-dev-polygon using containerization directly on the developer's machine.

    Also, for each polygon in the repository, its own branch is created, the commit to which should initialize the automatic deployment of the fresh release to the polygon. With prod, as a rule, they do not do anything, but I think this is purely for personal reasons.



Suggested Topics

  • 2
  • 4
  • 2
  • 3
  • 6