tdd – Kownter https://blog.kownter.com Simple, private, self-hosted, cookie free website analytics...one day...maybe Thu, 03 May 2018 07:13:43 +0000 en-US hourly 1 https://wordpress.org/?v=6.7.2 Adding “simple” features https://blog.kownter.com/2018/05/03/adding-simple-features/ Thu, 03 May 2018 07:13:43 +0000 https://blog.kownter.com/?p=60 Read more]]> I recently added a “simple” toggle so I can show information from different time periods.

Animated GIF of time period toggle

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:

  • try building some Vue.js components
  • practice using the JavaScript fetch API and promises

And to use fetch I had to write an “API” endpoint to grab the relevant data. So the process for building this was:

  • write tests for the API endpoints (which, in my case, involved be building some factory classes too – a job that needed doing anyway)
  • write API endpoint routes
  • write API endpoint controller methods
  • create the Vue components
  • plug it all together with the API calls

(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.

]]>
Getting going https://blog.kownter.com/2018/02/24/getting-going/ Sat, 24 Feb 2018 10:04:49 +0000 https://blog.kownter.com/?p=11 Read more]]> I’ve now got a fresh install of Laravel, which will be the framework I’ll try to build this on – it’s both the framework I’m most familiar with, and the one I’m trying to learn more about.

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:

  • a_page_view_can_be_tracked
  • a_page_view_for_an_unknown_domain_fails
  • a_page_view_logs_the_correct_user_agent

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:

]]>