BUT…this is one of this things that seems trivial but really isn’t because of the kinds of engineering decisions you might make.
In this case I’m building and learning test-driven development as I go, and I wanted to use this as an excuse to:
And to use fetch I had to write an “API” endpoint to grab the relevant data. So the process for building this was:
(You’ll note that I’m not testing the front end)
Yes, this is modern web development. And yes none of it was particularly difficult. And yes, it all works fine. And yes, having done this once, subsequent, similar functionality will be quicker to build. But I thought this was one of those insights into how a tiny, trivial looking user interface improvement actually has many moving parts.
]]>I’m going to try to take an approach called “Test Driven Development” (TDD) – which I’m also trying to learn more about. This process involves writing an automated test BEFORE you write the code that makes the application work. So the test you write fails, and then you work until the test passes.
I’ve seen TDD done one test at a time, but I already have an idea of what tests I will need to write, so I’ve gone ahead and added a bunch of tests by name only. Thinks like:
These tests aren’t fleshed out yet, they’re reminders of what I need to write. I have some idea of what I will need for this to work. And I’d normally keep these as todos somewhere, but I’m trying to use my test names as my todos here.
I’ve also got some of the code working and tests passing. I can basically track a simple page view right now.
I’ve also created a test for being able to display the results and coded that up to get it passing too.
So, right now, I’ve got something that looks like this: