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.

Budget Pro alpha release

Screenshot of the Budget Pro budget overview and test saying "Budget Pro is Budget on steroids - it's everything you love about Budget improved in every way. More viewing options, more controls, you name it."

We did it! The Budget pro alpha was released. We promised to release the alpha in the first half of the year and we did it.

This post is a little late, the release happened on 2nd June. Since then, we have pushed out several updates as we work towards the beta and the official release. We are working as hard as we can but as per our previous post, we are taking it slow. We want the official release to be as smooth as possible.

During the alpha we are fleshing out the features that make Budget Pro different to Budget and working on the initial user experience. As soon as we get to the beta, we will focus on the collaborative side of Budget Pro.

Budget Pro is usable now if you are willing to do a little data entry at the start. We are working on improving the initial experience and providing several different tools to help you get started. At a certain point though you need to release. If you wait until the next feature is ready, you will never release anything. We are using Budget Pro for our own budgeting needs and like Budget, it is capable even at this early stage.

There is a page on the Budget Pro website which details everything we are planning for the alpha and beta and our status.

It has taken a long time to get to this point. We had to build the API, build the wrong App, build Budget, create some game scorers, and then create Budget Pro. We are proud of what we have created so far and hope it will be a useful tool to many. We understand that whilst budgeting isn’t the most exciting task, you can reap the rewards once you have it established and it opens possibilities. Once we know where we are, we know where we can go.

Please check out the website and let us know what you think. Anyone that signs up before the official release will get gifted a subscription once we release.