wissel.net

Usability - Productivity - Business - The web - Singapore & Twins

Adventures in TDD


There are two challenges getting into TDD:

  • Why should I test upfront when I know it fails (there's this massive aversion of failure in my part of the world)?
  • Setting up the whole thing.

I made peace with the first requirement using a very large monitor and a split screen, writing code and test on parallel, deviating from the ?pure teachings' for the comfort of my workflow.

The second part is trickier, There are so many moving parts. This post documents some of the insights.

Testing in the IDE

TDD has the idea that you create your test first and only write code until your test passes. Then you write another failing test and start over writing code.

As a consequence you need to test in your IDE. For JavaScript or Java that's easy (the languages I use most):

  • In JavaScript you define a script test in your package.json you can run any time. For a connoisseur there are tools like WallabyJS or VSCode Mocha Sidebar that run your tests as you type and/or save. The tricky part is: what testing libraries (more on that below) to use?
  • In Java Maven has a default goal validate and junit is the gold standard for tests. For automated continuous IDE testing there is Infinitest
  • For Salesforce you have a combination of JavaScript and Apex (and clicks-not-code), testing is a little trickier. The commercials IDE TheWelkingSuite and Illuminated Cloud make that a lot easier. How easy is in they eye of the beholder. (Honorable mention: JetForcer - I simply haven't tested that one yet)

Testing in your Continuous Integration

Automated testing, after a commit to Github, GitLab or BitBucket happens once you configure a pipeline as a hook into the repository and have tests specified the pipeline can pick up. Luckily your maven and npm scripts will most likely work as a starting point.

The bigger challenge is the orchestration of various services like static testing, dependency management and reporting (and good luck if your infra guys claim, they could setup and run everything inhouse).

Some of the selections available:

What to test

There are multiple dimension you want to test. Not all of them at each moment in the development workflow. The rule of thumb: move from microtests (testing the code in the current editor focus) to "all bases covered" in your release branch. The closer to a release, the higher coverage needs to be.

  • Test that run without backend data
    • Unit tests: Does your code run without errors
    • Assertions: Does your code compute correctly
    • Coverage: Is your code sufficiently covered with tests
    • Quality/Style: Is your code understandable and can it be maintained
  • Tests that need backend data
    • Component tests: Do component correctly receive and return data
    • API tests: Do the APIs react as
    • UI tests: Do interactions work on all targeted devices
    • Load tests: Does the environment scale

The later is the hardest: your test environment most likely is setup differently than production, so a performance test, not run in production, doesn't tell you that much.

Tools in my chain

I can say "all of the above" and I do have my favorites, some out of convenience, some out of conviction:

  • IDE
    • Visual Studio Code for HTML, CSS, JS including WallabyJS for UnitTests
    • Eclipse for Java (and XML using the oXygen plugin)
    • The Welkin Suite for Salesforce
    • Sublime for arbitrary files
  • Version Control
    • Bitbucket for my private repositories
    • GitHub for the public (not moving)
  • CI: No clear favorite. I like the Bitbucket and Heroku pipes, since they are integrated into source or target environment. I used the others too. Fond of Travis (my German bias ;-) )
  • Testing
    • Maven/JUnit for Java
    • PMD for static code analysis (Java, JavaScript, Apex)
    • Mocha for JavaScript. You will find the JavaScript environment changing fastest. Fortnightly there will be a new testing framework to rule them all. Lots of them a beverage themed (Mocha, Jasmine, Chai). Pick one, stick to it, write lots of tests. Hint: If you have to pick: switch the framework or write more tests?
    • Chai for test in Postman
    • Lightning Testing Service for Salesforce Lightning components
  • Documentation / Paperwork

As usual: YMMV


Posted by on 10 June 2018 | Comments (4) | categories: JavaScript Salesforce TDD

Comments

  1. posted by Nick Wall on Tuesday 12 June 2018 AD:

    One of the best bits of TDD for me is, I find the dev process so much quicker, especially TDD for web front end as you hardly ever need to launch the app to see if working.

    An interesting take on testing here from assert.js conf a few months back.

    https://www.youtube.com/watch?v=5FnalKRjpZk
    https://www.youtube.com/watch?v=Fha2bVoC8SE


  2. posted by Kalpesh Darji on Wednesday 12 September 2018 AD:

    Failing tests challenge the developer in a positive way. They will say aloud ???I think this will pass??? and ???I do not think this will pass??? or ???I???m not sure, let me think after I try this approach.???

    This type of reinforcement is key to communication, not only to predict your next action but also to reinforce the concepts of writing the simplest code to make a unit test pass.

    Here's the blog (https://www.simform.com/what-is-tdd/) which explains the how TDD works in three steps: Red, Green and Refactor.


  3. posted by Ed on Wednesday 12 September 2018 AD:

    What software is testing your test software. Dont you need to write a tes to test your test software? Where does it end? Does anyone take in consideration the extra time? I always get the answer, in the long term, it will be easier to maintain etc. But if it it doesn't have to be maintained in the future, you wasted a shitload of time.

    There is a lot of software out there, written without TDD and still running without modifications.


  4. posted by Stephan Wissel on Wednesday 12 September 2018 AD:

    @Ed - reminds me of a line in the song by the Alan Parsons Project:

    "Well you really are persuasive,
    But I've heard it all before
    "

    First: I've yet to see a software that never got changed. Secondly: your perspective is ex-post: bolting testing onto an existing software quite often isn't worth the effort.

    However, the main point is to create testable software from the very start. I've seen this quite often: use a split screen to write test and function together. It automatically leads to cleaner code. Since cleaner code is easier to debug, you already save time.

    Another flaw in the argument: "Oh 100% testing everything is such an effort, son any testing isn't worth it". Testing isn't binary, it's a scale from 0-100%. You can expect a exponential curve in effort. So you need to find the spot you can afford in your (time) budget. Given test first mindsets actually save time, you will be surprised how far you get.