week of 01 april

01 Apr 2019

01 apr

New week, new testing fails!

Here are the tabs I left open from last week:

I’ll read some of that and see where it takes me.

More reading, more youtubes. I watched some legacy codebase talks that sent me down the path of looking at end-to-end testing instead of unit testing. Since a legacy codebase has so much going on, unit testing can be very difficult, especially for figuring out where to start. Starting with E2E tests gives you test coverage of an app’s behavior, so when you go back and start refactoring/adding unit tests, you can maintain that behavior without screwing things up too much. At least, that’s the idea I’m getting with all this.

SO. Even though I’ve spent a lot of time trying to set up jasmine/karma, I’m going to pivot to trying out cypress. I’ll add a new branch to the repo and begin anew! If it turns to be too much of headache, then I’m not really sure what I’ll do after that. But I also have a copy of Michael Feathers’ Working Effectively with Legacy Code, so maybe I’ll have a better roadmap later this week. I guess we’ll wait and see what happens!

02 apr

Time to get Cypress.io set up.

Setting up cypress was very easy! I got the hours app demo up and running basics tests very quickly, which was a pleasant surprise. Now… what to test?

After some additional youtube watching and article reading, this seems to be the consensus on E2E tests:

E2E workflow

  1. Build user functions
    • list the features of the system and their interconnected components
    • list input data, action, and output data for each feature/function
    • identify relationships between functions
    • determine whether function can be reusable or independent
  2. Build conditions based on user functions
    • build a set of conditions for each defined (above) user function
    • conditions include sequence of events, timing, data
    • examples: invalid UN/PW, PW strength checks, error message for invalid options, etc.
  3. Build test scenario
    • at least one per user function
    • definitely more if there are multiple conditions per function/feature

I always have a hard time deciding where to start, and several articles suggested focusing on the most important tasks. What are the most important tasks of the hours app?

03 apr

The Legacy Code book came yesterday! I’m going to spend a good amount of time today reading through it and taking notes. Yippee!

I’ll write up my notes here, but before I forget, this article on stubbing HTTP requests with sinon looks very, very useful for the future.

preface

ch 1: changing software

ch 2: working with feedback

ch 3: sensing and separation

ch 4: the seam model

04 apr

More from the Legacy Code book today.

ch. 19: My project is not object-oriented, how do I make safe changes?

Based on what I’ve read so far, it’s going to be better for me to start with covering large areas of code and working my way to smaller bits of code. Broad => narrow, which means starting with end-to-end tests, moving down to integration, and finally working on unit tests of individual components like functions, controllers, directives, modules.

05 apr

Spent the morning setting up cypress and writing tests. It’s amazingly easy and so awesome to see tests running in the browser! I’m going to need to write tests for individual pieces of the app and for each page/view change, so it might take a while, but this is definitely going to be beneficial. I’ve already spotted some weird accessibility stuff by writing these tests, so it has already been worthwhile.

In the afternoon, I switched back and forth between testing and setting up my laptop. It was running Sierra, so upgrading it to Mojave took about 2 hours. Then pulling down my dotfiles and setting up all my apps and development environment took quite a bit of time (turns out my documentation wasn’t as solid as I thought it was!), so that was most of my afternoon. But now I can work from anywhere! Huzzah!