With the rise of automated testing as a practise high performing technology organizations do, it's time to broaden the horizon and look past the application code. Every piece of code responsible for delivering value should also be tested. In this post, we will take the shell into the warmth and make it a first class citizen in the automated testing regime with bats.

Testing, testing

Testing shows the presence, not the absence of bugs. - Edsger W. Dijkstra

As professional software developers, writing automated tests has become second nature to what we do. The exact amount of tests, amount of code-coverage, unit vs. integration vs. integrated test etc. may still be up for debate, but the industry as a whole seems to have settled on the practice of automated tests as a way to ensure the viability of a codebase over time. The Extreme Programming methodology of the late 1990's even went as far as citing "Code without tests may not be released". Even with the general consensus among developers that automated testing is something we should do, it's still an open choice: one can actively choose to not to write tests as well.

Dave Farley wrote a blog post some years ago about how we should use techniques from classical science and engineering and apply them to software development to make the field "a real engineering field, not just a pretend-to-be", and to archive this, testing is essential. To be frank, in how many other engineering fields is testing of the things created optional?

Used correctly, automated testing is a great way to implement the essence of science, to falsify the hypothesis about the code.

Every programming language or ecosystem that's worth taking seriously has a testing library, or sometimes whole frameworks created for them. For C# and dotnet xunit has become somewhat of a standard, in Java and JVM land JUnit has been around for a long time, and for JavaScript, both frontend and backend, testing with Jest has seen a lot of traction.

Writing our unit, integration or integrated tests in the same language as the production code and keeping the tests close is the de facto standard.

But aren't we forgetting something? Our systems do not stop at the application code level. To be able to build and deploy our code, chances are we have some build scripts and deployment pipelines, or some good old "glue scripts" keeping it all together. To do most of this heavy lifting most of us still depend on the good old shell scripts, most notably written in the old work-horse Bourne Again Shell, or Bash.

If anything, chances are slim that Bash is going away anytime soon, and scripts written for the shell deserves tests of it's own. The shell is also often forgotten as an environment to test systems from in of itself. There are lots of CLI's that can be used to test different aspect of our systems, and there is no rule proclaiming that integration or load tests need to be written or hosted by the same codebase as our application.

It's time to introduce shell testing with bats.


Introducing shell testing with Bats

bats is a TAP, or "Test Anything Protocol" compliant testing framework for Bash. It provides a simple way to verify that the *NIX programs you write behave as expected. The initial public release of bats was done back in 2011 by Sam Stephenson, but the project was archived and put in a read-only state in 2016. As of 2017, the current actively maintained fork, know as bats-core has been looked after by the bats-core organization, and the project is still under active development.

To show how writing tests with bats work, let's write some black-box test verifying a REST-API with curl. Our "system under test", or "SUT", is the The Star Wars API. This will show how bats work, and show one of it's use cases.

We begin with a test to make sure Luke Skywalker is the first entity of the /people endpoint. As we will see, tests are set up like most other testing frameworks, here following the "arrange act assert" pattern.


To run the test, use the bats command:



We can expand on this and check if the /planets endpoint contains Naboo:

The two tests are now run together:

Great. Those examples show the overview of bats. For more ideas on how to use bats for integration tests, Zach Holman has a great blog post with that topic in mind.

Next, let's spice it up with some Test Driver Development (TDD) on some actual shell scripts.

Using TDD in our shell scripts for fun and profit

Let's begin simple: We want a function to extract the author from a markdown file containing book notes, but want the job to exit if no argument (I.e. a file) is given. This being TDD, we want a failing test explaining the logic we want before we actually write som code.

In this example, we will see the keyword run, which is used to run a function, as well as the $status and $lines variables provided by bats. The overview of bats variables can be found here.

When run against an empty file, this test will (not surprisingly) fail:



And if we fill in the code:

And run the tests again:

We get some green tests.

Cool. Now for the functionality. We want to extract the author from the markdown notes file:

Again, let's start with the test:

And that test will fail since we don't have updated our code:

Cool. Now let's do some regex-matching, an operation that's good to have tests for:

Note: For this pice of code, the GNU version of grep is used. It might not work as expected on macOS with BSD grep.

With this pice of code in place, the test should be green:

And indeed it is.

Don't believe the hype? Let' try the method ourself:


Don't you know it, it works! Tests don't usually lie.

How about the title? We have the author, but not the title? That's kind of backwards. Let's begin by specifying how the function should look, again from our tests:

Same as before, no file should give output and exit code 1. No code written yet, no green test.

With that in place we can focus on extracting the title from the file. As always, the test first:

How do you think running this test will go? That's a no. We don't have any code yet.

Let's break out that regex to match the title from the markdown:

With this line in place, the tests go green:

NICE. But wait. What about refactoring? Isn't that a part of TDD?

Yes indeed. The observant reader may have seen that the two functions have something in common: both take in an argument of a file name for parsing, and both do the parsing based on regex expressions. If no argument is given, return error exit code and a message saying "Missing Argument file".

Let's begin by extracting the input validation from the get_author and get_title functions and call it _file_exists. This function will be more generalized and standalone. As always, the functions behavior is first described with tests, which makes for great documentation of the function.




Then we can extract the input check directly from the functions:

Now here we could also extend the _file_exists code with a branch handling an argument of the name of a non-existing file, but to stay strictly in line with TDD we should only add enough production code for the tests to to pass, which we have done with the extracted snippet.

The refactored get_author function now looks like this:

How about the tests?

Did the code get any better or clearer? More dynamic and with a better abstraction. Thanks to the tests the refactoring could be made safer with guardrails.

Conclusion

In this post we have seen how our shell scripts also can have automated tests thanks to bats. Hopefully this will motivate you to extend your thinking about tests to also include the pieces outside the application code.

As a colleague of mine said: "Every pice of code in the repository that is necessary to bring value to the customer is critical, and should thus also be tested. If we think we have a bug in the deployment pipeline, we don't guess. We test and prove.

All code examples from this post can be found in this Git repository.

Extend your automated tests to the Shell

In this article I will show how you can infer the value of a property in any object with generic typescript.

This articles assumes you are already familiar with generics in typescript.

Working with generic values in typescript can be difficult. Especially when we want to create constraints where one value knows something about another value. In this example we will look at how we can connect a property key with its value type over two different generic values.

Let us start with the following definition for an object. This will be the object we can test our code with:

The wrong way

We now want to create a type that lets us define the keys of our object and it's values. We could do something like this:

But it will not work exactly how we like it to work. Although key is defined as a key from our object (K extends keyof T), it isn't able to connect that the key "name" should have the value string. Instead it assumes that value must be one of the possible values in our object. In this case it could be either string, number or boolean.

What we want is to create a type that will give us an error if value has the wrong type for the given property name.

The right way

Instead of using <T, K extends keyof T>, we start by creating a type that lets us get all the values of an object.

If we call ValueOf<UserType> it will give us string | number | boolean.

We then use ValueOf around the object type we want to define.

Now it works! It does give us an error if we try to set value to anything other than a string.

Let us take a closer look at this type to understand how it works. If we where to use it with our UserType we would get this:

We have created one definition for each of the properties in UserType. This way we have created a connection between e.g the key "name" and its correct value type string.

A smarter way of using T[keyof T]

Dagens designtips er en artikkelserie hvor forskjellige designere fra Bekk snakker om jobben de gjør, hvilke utfordringer de møter på, og kanskje kommer med et lite tips.

Hvem er jeg?

Frida heter jeg!

28 år

Fra Holmestrand

Studerte design på Arkitektur- og designhøgskolen i Oslo.

Jobbet som designer i 3 år

Jeg trives som problemløser og formgiver. Tanken om å jobbe kreativt har alltid vært der, men at det var å bli designer var litt tilfeldig. Etter klønete opptaksprøver kom jeg inn på studiene i Oslo, uviten om hva faget innebar. Kort tid etter forsto jeg at designmetodikk er mer enn å skape, noe som ga meg en motivasjon jeg ikke visste jeg hadde. Det å lette på smertepunkter og lage noe verdifullt er en kombo jeg liker!

Hva gjør jeg og hvordan?

For tiden jobber jeg sammen med flinke folk der vi bygger Kartverkets designsystem. Det er et veldig spennende prosjekt og som ny kunde av Bekk får vi være med helt i starten med å etablere gode metoder, leveranser og miljø. Kartverket leverer ulike tjenester og det er nyttig å samle designelementer, komponenter og kode slik at vi har en kjerne til en felles sannhet. Et designsystem er ikke bare en «nice to have», det bidrar til effektiv jobbing der man kommer raskere i prod, blir mer konsise og vi kan redusere «unødvendige» oppgaver og dobbeltarbeid. Det blir også enklere gjenbruke kunnskap og løsninger som allerede er løst av organisasjonen. Dette hjelper oss også på veien mot brukervennlige løsninger og til en helhetlig brukeropplevelse.

Det kan kan være tungt å starte på bar bakke når det kommer til designsystem. Man har veldig lyst til å fikse alt samtidig, noe som resulterer i at man ikke får levert noen ting. Som en detaljorientert sjel må jeg minne meg selv på at et designsystem som venter på å bli lansert gir ingen verdi. Derfor er det nyttig å lage en enkel utgave å starte med, som man så kan lære av og bygge videre på.


Hvilket tips ville jeg gitt meg selv i starten av prosjektet?

Til tider kan det virke overveldende. Da må man huske at man ikke er den eneste som skal få designsystemet på plass. Tør å delegere og bruk andre fagpersoner, og la dem slippe til for å bidra på prosjektet. Det er sjeldent at én person kan forutse hva alle trenger, derfor må man ha tillit til at kollegaer på andre prosjekter kjenner sitt produkt og sine brukere godt. Det vi kan gjøre er å tilrettelegge for at de kan jobbe effektivt og løse nye utfordringer når de møter det, og de selv kan bidra tilbake til designsystemet.

Så mitt oppsummerende designtips er: Du må ikke gjøre alt perfekt alene. Bruk hverandre og det trenger ikke være plettfri med det samme. Gi verdi fra dag én, da slipper vi timevis med arbeid om antagelser rundt bruk og vi kan heller bruke reell innsikt for å iterere det vi lager.

Dagens designtips

På første møte med UU-faggruppen i Bekk var målet å bli kjent med de fire inndelingene av utfordringer som vi finner i samfunnet vårt. Vi var to stykker som kjørte en litt kreativ vri for å teste det å slite med motorikken, hvor kollegaen mi skulle navigere mens jeg ga henne ukontrollerte skjelvinger og bevegelser i hånda. Det ble fort tydelig hvor ekstremt vanskelig og ikke minst frustrerende det var å navigere seg rundt på nettsiden. Likevel har dette blitt en brukergruppe jeg tar meg selv i å glemme gang på gang. Jeg har det alltid i bakhodet at jeg skal hjelpe brukeren ved å beskrive en eventuell feil ved input, ha god nok kontrast og bruke enkelt språk… Men tenker jeg egentlig nok over hvordan jeg kan lage løsningen tilgjengelig for de med utfordringer med motorikk?









Hva innebærer det for brukeren?

Brukere med motorisk funksjonsnedsettelser vil typisk slite med skjelvinger, svak muskulatur og/eller mangler ved håndfunksjonen. Nedsatt motorikk påvirker hvordan en håndterer PC, nettbrett, telefoner og andre digitale dingser. Personer i disse målgruppene trenger ofte andre måter å styre og navigere digitalt utstyr enn med vanlig tastatur og mus. Det kan være skjermtastatur, joystick eller øyestyring. Mange kjenner på utfordringer med å navigere seg i det fysiske miljøet og internett kan da være en viktig kanal for å kunne delta i samfunnslivet på 

I et blogginnlegg på UU-tilsynet blir man kjent med Inge som for syv år siden ble lam i hele kroppen. Inge bruker hodemus for å navigere - den følger med når han snur på hodet og klikker i det han biter i en bøyle. For han ble spesielt nettsider med tidsbegrensning på input av informasjon en utfordring. Se for eksempel for deg billettbestilling. Ofte får du tre minutter på å fullføre alt, inkludert betaling før du «rykker tilbake til start». Nedtellingen vil nok sannsynlig være stressende for en med normal motorikk, men ekstra ille blir det for Inge som ikke klarer å bite tennene sammen fort nok til å rekke fylle ut skjemaet. For han ble autofyll-funksjonen på nettleseren en redder. Les mer om Inges bruk.







Hvordan kan vi bidra?

Som påpekt i Inges eksempel er tid et nøkkelord for å tilgjengeliggjøre siden. Brukeren bør få mulighet til å selv bestemme tidsbegrensninger og muligheten til å gjenoppta der hen falt ut. Det er også viktig å være bevisst om å begrense mengden informasjon brukeren må oppgi (ikke lovkrav, kun anbefalt). 

For andre er det vanskeligere å bruke mus, så derfor må alle nettsider kunne navigeres med tastatur. Å kunne bruke nettsider med tastaturet er både bra for en med nedsatt motorikk og for en med brukket arm etter et ambisiøst hopp i bakken. Kravene til tastaturnavigasjon innebærer logisk tastaturrekkefølge, at brukeren ikke skal bli stående fast i et element, å ha en snarvei som lar brukeren gå rett til hovedinnholdet og at det ikke skjer automatisk kontekstendring når brukeren navigerer med tastaturet. Når man skal bruke tastaturet for å navigere seg er det ekstra viktig med oversikt over hvor hen er. Mange brukere er avhengige av støtte for å forstå hvordan nettstedet er “skrudd sammen” - for eksempel bør menyvalget for den gjeldende siden markeres visuelt, men ikke være lenket. 

For både Inge, kollegaen min og meg er det tydelig hvor viktig store klikkflater har å si for at nettsiden skal bli brukbar. Det er både viktig på desktop og når man skal benytte seg av berøringsskjerm. Både størrelse på og avstand mellom objektene er viktig. Med korrekt kodet ledetekst blir både tekst og avkryssningsboks klikkbare. 







Jeg har også lyst til å tipse om en podcast jeg hørte på for en stund tilbake som jeg synes var veldig interessant


Tilgjengeligjør for motoriske funksjonsnedsettelser

Det er leit å melde. Det er ikke lenger en god idé å rendre hele websiden din på klienten. En SPA er rett og slett ikke bra nok i 2022.

Et historisk perspektiv

De siste 10 årene i frontend-verdenen har vært ganske… interessante. Skikkelig hektiske, faktisk. Vi har gått fra å ha nesten all logikk på serveren, via å ha noen kladder med jQuery-spaghetti her og der, til å lage både klient-monolitter og micro-frontends.

Vi gikk fra JSP til JSX, og besøkte både Backbone, Angular og Ember på veien. Vi var innom både CoffeeScript og Ruby on Rails, men endte opp med en ganske samla front rundt React, TypeScript — og kanskje litt Elm.

For det var single page applications — apper som kjørte på klientsiden — vi landet på som den best mulige løsningen. Vi laget en tykk klient, spurte noen APIer, og viste frem dataen. Grei skuring.

SPA er ikke bra… nok

Det føltes en stund som vi, på sett og vis, hadde løst frontend-utvikling. Ting funka. Men SPAer — på tross av sine mange fordeler — sliter fortsatt med en rekke ulemper vi rett og slett bare har levd med frem til nå.

Det er fortsatt tregt

Den største ulempen med å ha så godt som all logikk i nettleseren, er at det krever en god del kode å implementere. Og når antall features i appen din går opp, vil tiden det tar før brukeren ser noe vettugt gå samme vei. Man må laste ned hundrevis av kilobytes med minimert JavaScript som må kjøres før noe skjer i det hele tatt!

Gode som vi er, har vi selvfølgelig kommet på teknikker for å delvis mitigere dette problemet, som å splitte koden i passende biter og hente det etterhvert som man trenger det. Dette fører riktignok til at du først må laste ned HTML-kode, så JavaScript-kode, som så genererer HTML-kode igjen. Og først da fyrer man av gårde eventuelle API-kall for å vise det faktiske innholdet!

Nettverk og vannfall

Et fenomen vi ofte ser er at selv om nettleseren potensielt får opp en slags ramme rundt nettsiden din ganske kjapt, vil det første som skjer være en rekke kall til diverse autentiseringstjenester og backender for å hente den dataen vil vise. Og mens vi venter på dem viser vi en spinner.

Andre ganger trenger man å gjøre et nettverks-kall før man gjør et annet. Som fører til spinnere som flytter på og formerer seg. Og før du vet det sitter man og teller spinnere som dukker opp og forsvinner, flytter på innhold og gjør siden din mer slitsom å se på.

Det hjelper ikke at du fikk opp logoen din fort, når man fortsatt må vente 10 sekunder før ting er klart. Om noe så husker man hvem som ga deg en dårlig brukeropplevelse.

Vi mister SEO og forhåndsvisning

En annen konsekvens av å kjøre alt i nettleseren er at vi har mistet muligheten til å dynamisk sette innholdet i meta-taggene som brukes av søkemotorer og sosiale nettverk. Det betyr at innhold som før var enkelt å søke i og forhåndsvise nå kun kan vise frem en generisk beskrivelse av nettsiden din. Du kan heller ikke sette språket siden din vises på dynamisk, som vil hindre muligheten man har til å søke etter innhold på et gitt språk.

Når alt vi serverer til brukeren er en tom <div /> tag, er det ikke rart at det blir vanskeligere å indeksere innholdet ditt. Det er ikke alt innhold som skal indekseres, men det skader aldri å følge anbefalinger som fører til god indeksering på søketjenester.

Ingenting fungerer uten JavaScript

Et siste argument jeg vil nevne er at ingenting i en SPA fungerer om JavaScripten ikke er både slått på, lastet, og fungerer. Du får ikke opp innhold, du får ikke navigert deg rundt om på siden, og du får i alle fall ikke utført noen endringer! Det burde ringe en varselbjelle når det første man gjør i alle skjemaer er å kalle en funksjon som heter preventDefault.

Det betyr at man er beint nødt til å vente til alt er lastet før man i det hele tatt begynner å konsumere innholdet. Det finnes ingen grasiøs degradering av brukeropplevelsen — det er enten alt eller ingenting. Det er rett og slett ikke bra nok.

Statisk sidegenerering er ikke godt nok

Tankegodset jeg kommer med her er ikke nytt – og det har vært mange forskjellige forsøk på å løse disse utfordringene. Et av de som fikk god traction en periode var den såkalte Jam-stacken, der man brukte verktøy som Gatsby for å generere statiske HTML-filer, som så ble sendt til nettleseren, sammen med kode som gjorde dem interaktive etterhvert (såkalt hydrering).

Dette fungerte fint for statisk innhold, men med en gang man skulle være logget inn, måtte man rendre innholdet på klienten igjen.

Og ikke minst — jo mer innhold du hadde, jo lenger ble byggtiden din. Joda, man fikk etterhvert til inkrementelle bygg på visse infrastrukturer, men det er fortsatt langt fra godt nok. Og hvem liker vel vendor lockins?

Fremtiden er på serveren

Heldigvis har vi bedre måter å løse webutvikling på i 2022. For jeg mener at fremtiden av weben — den løses på serveren, og krydres på klienten.

Remix og Next.js er to rammeverk som gjør nettopp dette for oss. De lar oss generere sidene våre på serveren, returnere ferdig HTML, som så blir gjort interaktiv (eller “blir hydrert”) av kode som lastes etter brukeren har fått opp innholdet sitt.

Tilpasset innhold uten spinners

Det at vi nå vet hvem som spør om en gitt side, gjør at vi kan generere innhold for den brukeren, eller for brukere med spesielle ønsker, uten å vise en eneste spinner. Og med React sin nyimplementerte støtte for å kunne strømme resultater tilbake til klienten litt etter litt, kan man fort begynne å oppnå raske lastetider også her.

Mange sider og API-kall kan også gjøres raskere med caching — både på klienten og på serveren. Og ved å sende de riktige caching-headerne når en viss side lastes, kan den mellomlagres på CDNer, og oppleves som vel så rask som en helt statisk HTML-fil.

En annen fin konsekvens av å bruke et rammeverk som Remix er at man kan utlede databehov fra URLen man er på. Og når man vet mer om hva man trenger, kan man starte flere requests samtidig, som igjen gjør appen din kjappere.

Mye mer grasiøst 🩰

Remix er spesielt godt egnet for å lage løsninger som grasiøst degraderer seg om JavaScript skulle feile, eller ikke laste av en eller annen grunn. Den faller nemlig tilbake til de innebygde defaultene som nettleseren shipper med. Det er kanskje litt mer kludrete, men det fungerer godt i en knipe.

Det gjør også at du kan sende inn skjemaer eller navigere rundt på siden før JavaScripten er helt lastet inn – istedenfor å vente på at JavaScripten skal lastes. Det gir både deg og brukeren din et sikkerhetsnett, til og med når koden din kræsjer.

Høyere krav til både app og utvikler

Applikasjonene vi lager er mer avanserte, gjør mer, og stilles stadig høyere krav til. Man skal kunne bruke dem på mobilen i en tunnel, like enkelt som man kan skal kunne bruke dem på jobb. De skal være raske, tilgjengelige, delbare og gøyale.

Men vi har lært noe de siste 10 årene. Mulighetene for å lage gode løsninger som oppleves bedre for flere er definitivt der. Men å sende en megabyte med JavaScript til nettleseren din er ikke riktig tilnærming. Å kjøre samme koden på serveren, derimot, er det.

Vi må slutte å lage ting som kun kjører i nettleseren. Vi har bedre verktøy i verktøykassen, og vi kan skape bedre brukeropplevelser uten nevneverdig merarbeid. Og det høres ut som en god deal i min bok.

7-Dec

Today's posts

Extend your automated tests to the Shell

A smarter way of using T[keyof T]

Dagens designtips

Tilgjengeligjør for motoriske funksjonsnedsettelser

Ha det bra, SPA