I am Nico,
I am a senior engineer for a ticket broker based in London.
From the office! is a daily (almost) posting routine that I keep to journal about the tech things I have been doing in my day-to-day office life.
The story
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.
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 some 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 response
pm.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 properly 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 the new domain and check if every one of them passes.
What is your take?
What do you think about the testing outside the repository?
Is it worth adding these tests into your daily practice?
Also, how would you refactor really old code?
Write your thought in the comment below.
Conclusion
I have been a web developer for almost a decade now.
Working with world-class businesses and award-winning marketing agencies situated in the heart of London.
Also, I write articles and tutorials on my blog and online communities and help businesses build their presence online.
Top comments (9)
I kind of like your approach of testing the API first, at least for a start (I've barely written any PHPunit tests myself, so I can't really say anything about it).
But regarding Postman, in order to make sure the API returns the expected fields, especially with deep nested objects, it helps to test against a JSON Schema.
I tried to lay out my findings here
marcus-obst.de/blog/validate-compl...
I hope it makes sense
It's not perfect, because I had to assign the JSON Schema in JS variables, and then they get loaded into
ajv(the testing library), so the schema is not very portable. Everything happens within Postman. (I wrote a script in Postman that exports the schemas into json files, because I thought I could use those schemas in my PHP app to validate the API I consume).Thanks for the comment, how come you haven't written PHPUnit tests?
The usually reasons: nobody asked for tests (only when I contributed to open source projects :D), not taking the time to get into it and understand it etc.
But I always keep it in mind and will get there one day.
I understand, also the docs is not easy at all.
I might do a series of tutorial of if you and other readers are interested.
What whould you like to know in particular?
Here is something I have a hard time wrapping my head around and it's more related to contributing to open source (incl. writing tests ;-))
What is the easiest way to contribute to an open source project, while having it implemented in a current project?
Let's say I'm using guzzle and some cache middleware in a project. And I'm able to provide another cache provider that others might find useful, or update one.
What I want is turning the library that I improved into a forked repo, so I can send a merge request, and all that while staying inside my current project.
Most likely a test needs to be written for the enhancement and I want to do all of that right in the project where I use the code. Does that make sense?
I don't want to context switch as less as possible.
Any idea?
What you would do in that case is to clone the repo guzzle/guzzle and edit it rather than your repo.
Add the code for your feature + tests and send a pull request to their team.
Here are some examples:
#3057
#2525
#2500
What do you think about the the Postman testing suite?
Great article, really like how you framed and explained the usefulness of testing in Postman!
thank you Arlemi