Category: API

Posted on

REST API Tests

API Testing - White text on a blue background with multiple software based terms related to testing

If you review the tests for the Costs to Expect API, you will notice two things; I have a heavy preference for functional tests and I don’t tend to mock anything.

API tests and Mocking?

I don’t mock any services; I want my test environment to match my intended live environment as closely as possible. This means using all the services used by live, I want to know of integration issues prior to going live, all my API tests will run as though they were running on the live environment.

Additionally, my tests write data. They write data using the same system as live. If live writes to a MySQL database, so do all my API tests, I have never seen the point of using a different engine for testing, you are not testing like for like.

Functional tests

Most of my API tests are functional tests, they test a process. Unit tests are incredibly useful, but most of your tests should be functional or integration tests.

My goal with API testing is making sure everything works as expected for the user and any clients. Testing all the scenarios a user or client is likely to see, this means all the possible “400 errors”.

The unhappy path

We need to test the happy path but we should focus most of our effort on the unhappy path, this is where the awkward bugs lie and the bugs we didn’t find during development. In addition to testing the happy path, I include tests to validate the structure of data. I’m a massive fan of self-documenting APIs and include response tests which validate that the generated OPTIONS response matches what I expect.

My API action tests will include the expected, create, read, patch, and delete tests. They are not my priority, I create many more tests to ensure the correct validation messages are returned, ensuring parameters work as expected, testing where a user or client is likely to get stuck.

If there is a validation rule against a field, group of fields or some other explicit logic (PATCH body can’t be empty), I add a test to ensure it works as expected.

Postman collection vs local API tests

Up until recently, the API tests for the Costs to Expect API existed as a Postman collection. The collection worked until it didn’t. It is still a fantastic API monitor but as the scope of the API grew, it became painstakingly difficult to ensure the code and tests were inline, authoring tests is also tedious and slow with Postman.

I have/am moving everything local and testing with PHPUnit, I couldn’t be happier, tests can be tied to releases, I can run them without cost and although I’m still functionally testing, I’m not limited to setting some fixed input and testing only the generated output.

Posted on

Expose API requests

API inscription coming out from an open book, art style, digital technology

We all need to be more open with our customer’s data; where does it come from, how is it structured and used. Users should not be deterred from getting at their data and all our customers deserve more than a data dump. We are going to expose all the API requests on our apps, even our closed products.

Budget Pro

Budget Pro is our first commercial App under the Costs to Expect umbrella, it is not open source. It is the sibling to Budget, our free and open-source budgeting tool. Like everything under the Costs to Expect name, the App uses the Costs to Expect API. The Costs to Expect API is open source; it always has been and always will be.

Open

Being open is so important to us that anything we create which consumes the API, you could recreate for yourself. Our free Apps and game scorers are open source so you can extend them. We want you to use our tools but if you want to use your own, that is more than fine, over time we hope more developers will leverage our API. We appreciate that right now our API isn’t ready for prime time, we need to improve our test suite and finish rewriting our documentation.

One of our core philosophies is to be as open as possible. To support this, we will expose all API GET. HEAD and OPTIONS requests within Budget Pro. We don’t expose POST and PUT requests as you can’t review them after the fact without caching data which is troubling.

We are not gatekeeping your data. Ideally you will access your API data using out Apps, but you don’t need to. You can access the API directly, use an App created by another developer or create an App yourself, it is up to you.

Requests table

At the bottom of each page there will be a table which shows any API requests that were made to generate the page. The table will show the URI, request method, the response time, and some other nerdy values. To see an example, please check out our social experiment, it has been showing the same data since 2019. Budget shows similar data when you are signed-in. When we update our game scorers, we will add the same requests table.

We appreciate that to many users; this data is redundant. However, over time we believe the number of users who care will increase significantly. In the long term we think our effort will be appreciated and we hope to not be in the minority of Apps showing the data.