If you have been around the web development environment for a while you surely had came across the word ‘refactoring’.

 

What this word simply means is to improve the current state of the code without making substantial, or any for that matter changes to its outcome.

 

I have just changed jobs and my primary task in my new workplace is to replace an old Silex API with a brand-new shining modern Symfony 6 application using PHP 8.

 

First thing, If you are reading this without stopping and googling what Silex is Congratulations! you really have been around the block for quite some time.

 

Let’s talk coding now!

 

The initial problem I was facing was that the code I am working on is legacy code.

 

And I don’t mean legacy code the way Michael Feathers describe it in his book Working Effectively With Legacy Code

 

"To me, legacy code is simply code without tests." - Michael C. Feathers

 

I mean actually legacy, legacy code!

 

Remember the day you needed to set an array with the array() construct?

 

Yep, that legacy code!

 

The code of course had 0% test coverage and was incredibly intricate, knotty, elaborate, complex, cumbersome, bulky, and yes they are all synonymous just to let you understand the situation more clearly.

 

 

 

 

 

The problem

 

To me, step 1 of refactoring is writing code, integration then unit tests so that I know for sure that if I move some code around or create new classes, interfaces, etc, I won’t break anything.

 

The problem here is that I had in front of me 12, if not more, years of files consisting of 1200 to 3000 lines all linked to an App/App class that managed EVERYTHING.

 

From database connection to retrieving sessions to checking users' permissions and products, etc.

 

EVERYTHING.

 

There is no way I can touch that code without breaking something, most likely, business-core stuff.

 

The solution

 

I am quite sure we all have heard of automated testing before.

 

There are many testing libraries out there, PHPUnit, Mockery being the most popular.

 

This is great but this is all in-code testing.

 

What we, as a community, do not talk about enough is out-code testing.

 

…Introducing Postman…

 

What is Postman?

 

Postman is a platform for building and using APIs.

 

It is the main product in the field and has plenty of amazing features such as an API client, mocking servers, runners, monitors, and also testing.

 

That’s what we are going to talk about in this post

 

Why Postman tests?

 

Having tests is fundamental to be sure that your API is working as predicted, that the services are reliable, and that any changes haven’t broken existing functionality.

 

Postman allows you to write test scripts for each request.

 

The tests also work as a debugging process in case something goes wrong with your project.

 

Tests can be added to single requests, collections, or entire folders.

 

It also has a command line tool called Newman.

 

Do you know what that means?

 

You can actually run commands in the pipeline on your CI/CD system and have your API tested without changing a single line of code or adding PHPUnit to your fragile project.

 

That is awesome!

 

How to Postman tests

 

On the main Postman page for a given request you’ll find several tabs.

 

Params, Authorization, Body, Setting, etc

 

The one we are interested in here is Tests.

 

This screen is divided into 2 parts.

 

The main side on the left contains the actual tests you are running and a smaller aside that has a little example snippet of some tests you can try out.

 

 

As mentioned, the language those tests have to be written in is vanilla JavaScript, the language is so popular I am sure you won’t find any problem using it.

 

“Any application that can be written in JavaScript will eventually be written in JavaScript“ — Jeff Atwood referring to Atwood’s Law

 

Here is some example:

pm.test("Status test", function () {
    pm.response.to.have.status(200);
});
// where pm stands for the Postman object and the test is checking for a 200 HTTP responsepm.test("response should be okay to process", function () {
    pm.response.to.not.be.error;
    pm.response.to.have.jsonBody("");
    pm.response.to.not.have.jsonBody("error");
});// Well, those are quite straighforward, aren't they?

 

Another great feature when testing is the collection runner.

 

It enables you to run the requests in a collection in a particular sequence.

 

It logs your request test results and can use scripts to transfer data between requests and also tweak the workflow.

 

 

Even though these are not proper Unit tests, when dealing with a project so delicate I believe this is the best way to approach it.

 

Then, when the endpoint has been tested it is very easy to copy the tests over to the new domain and check if every one of them passes.