Blogthedata.com has no tests. There, I said it! But that changes today!

My test strategy begins with the testing pyramid

Testing Pyramid. The largest number of tests should be unit, then service, then UI.

The TDD Gods can look down on me for writing code without tests; I'll take it up with them in the afterlife. I will create unit tests FIRST for all code written from this day forward.

The plan is to have 100% unit test coverage. This is essential for when blogthedata.com is 'reactified' because it will break a lot of stuff. I expect separating the front and backend of the application to be difficult!

The second step is to write service level (also known as integration tests). My understanding of service level tests is that they cover two or more functions working together.

The third phase incudes UI level (or E2E (End-to-End), acceptance tests). I can write these using tools such as Selenium (browser automation) as well as manual tests run by a human. I created a free account for a testing tool called QASE where I've written a few tests.

E2E tests focus on whether the coded features fit the business use case, and the functionality makes sense to a user.

Screenshot of QASE UI showing two tests for Posts

Keep a watch on future PRs to verify I included tests!

Comments

Back to Home
John Solly Profile Picture
John Solly Profile Picture

John Solly

A hands-on AI practitioner who transitioned to a CTO role to broaden my impact.

Most of my career has been dedicated to developing spatial systems at Esri, startups, and federal agencies. Currently, I lead technology strategy for Leidos' Health IT division, supporting agencies such as SSA, VA, and HHS.

My primary focus is the convergence of spatial computing and AI, enabling machines to interpret the physical world and applying these capabilities to meaningful missions.

Please reach out if you are interested in spatial systems or advancing AI within the federal government.