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.
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).
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?
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