[Go Make Things] Buildless testing

By rahmat hidayat

Saturday, December 7, 2024

​ Earlier this year, I completely ditched build steps in my developer process for personal websites and small projects. My CSS is vanilla. I keep it organized in a bunch of small, modular files that I load individually as-needed (my SSG helps me out here). My JS is all vanilla, again individual files with the occasional ES module import. But the one thing that seems to require a build step is testing your code. Or does it? Let's dig in! I don't test enough Automated testing has always felt really onerous to me. I'm do a lot of manual testing as I write code, but manual tests has historically become things that break every time I make (expected) code changes, and always slowed me down. A lot of TDD (Test Driven Development) evangelists have insisted over the years that TDD—writing your tests first, expecting them to fail, and then coding until they pass—actually speeds up development. But I've long hated TDD, because it felt like I had to know what my code was going to be before I actually wrote it. Turns out, I've just been doing it wrong! TDD Revisited This talk from Ian Cooper on what's wrong with TDD totally rewired my brain! In it, Ian explains that… You should be testing public or developer facing behaviors, not how those behaviors work under-the-hood. If your tests break every time you change the under-the-hood behavior, even if the external behavior is unchanged, you're doing it wrong. A "unit test" could involve a collection of functions, so long as they operate as a discrete "unit." Tests should be fast, easy, and cheap. If they're not, you won't use them. This was a big aha! moment for me that made something click in my brain. (Ian also gave a follow-up talk called TDD Revisited that's worth a watch as well.) Then, as I was discussing the video with some friends online, my buddy Alex Riviere shared an article he wrote on testing a few years ago that cleared up the different kinds of things you're likely to test. Ian's talk on TDD focuses specifically on what Alex calls developer interface tests. Going buildless So, I'm sold on TDD, and I want to do it more often and reliably. But any testing tool that requires me to open up the command line, npm install, and run some scripts is going to fail the "fast, easy, and cheap" test for me. I won't use it reliably. As I was thinking about this, I remembered that my friend Baldur Bjarnason had been messing around with Node-free testing last year. His approach used Mocha and Chai with some command-line automations and a build-step. I decided to take his ideas and see if I could rip the command line and build-step parts out of it. Mocha, Chai, and the browser If you're not familiar with it, Mocha is really OG testing library that came out back when jQuery was still the way to write JavaScript for the web. It was designed to let you run tests using any of the mainstream testing libraries your wanted. It did the running, while you'd pull in another tool to do the actual testing. Chai is a testing library from that same era that was often paired with Mocha as part of a testing suite. While both of these tools were built for use with the command line, you can also just run them in a browser! And that means you can write and run JavaScript tests without ever having install anything, open up your CLI tool, or run a build process. Just open up an HTML file, and Mocha and Chai will display the test results right into the UI. An example Mocha published a guide on how to do this right on their website, but let's walk through my setup. First, load the Mocha CSS and JS files, and the Chai JavaScript file. You can host them locally, or use a CDN. <link rel="stylesheet" href="https://unpkg.com/mocha/mocha.css"> <script src="https://unpkg.com/chai@4/chai.js"></script> <script src="https://unpkg.com/mocha/mocha.js"></script> You need an empty <div> that Mocha can use to render the results into… <div id="mocha"></div> Next, we initialize Mocha, and tell it to run after the page finishes loading… <script> mocha.setup('bdd'); mocha.checkLeaks(); window.addEventListener('load', function () { mocha.run(); }); </script> Then, we can include and run our test scripts. You'll do this one of two ways, depending on your scripts are written. If your tests are written as an IIFE that adds global variables to the browser, include the script file and test file in the HTML… <script src="calculator.js"></script> <script src="test.calculator.js"></script> Here's a demo. Open the HTML file directly to see the tests run. If your tests use ES modules, you can import the script into the test, then load just the test as an ES module itself… <script type="module" src="test.calculator.js"></script> Here's another demo. Because this uses ES modules, you'll need to run a local server for the modules to work properly. What next? If you found this interesting, let me know and I'll write more about it! Things we didn't cover today that are on my mind… How to actually write tests. What to test. How to test DOM scripts like Web Components. How to use this buildless approach as part of a continuous integration (CI) process. Just to close out, thanks again to Ian Cooper, Baldur Bjarnason, and Alex Riviere for helping me understand this better. Cheers, Chris ​ Want to share this with others or read it later? View it in a browser.​ ​

Did someone forward this to you? Get Daily Developer Tips.

Don't want to get these emails? Totally cool. Update your subscriber preferences.

You can also unsubscribe from all emails from me, including updates to products you've purchased.

113 Cherry St #92768, Seattle, WA 98104-2205

Share :

Facebook Twitter Google+ Lintasme