söndag 6 februari 2022

Gherkin - det gemensamma "språket" från produktägare till utvecklare

Gherkin

Jag har nu haft möjligheten att använda Gherkin på jobbet, ett språk, eller kanske mer en mall, som används för att skriva systemtest så att de ska bli läsbara och förståeliga hela vägen från produktägare till utvecklare. Vi är bara i början av resan, men det verkar mycket lovande och intressant! Rekommenderar!

Om du är som jag och undrar varför saker heter som de heter så kan jag avslöja att gherkin betyder "liten picklad gurka". Och språket Gherkin används i testramverket Cucumber, vilket frun till skaparen fick namnge:

My wife suggested I call it Cucumber (for no particular reason), so that's how it got its name. I also decided to give the Given-When-Then syntax a name, to separate it from the tool. That's why it's called Gherkin (a small, pickled Cucumber).


Cucumber är ett Ruby-ramverk, sitter du med .net så är det SpecFlow som gäller om du vill skriva test med Gherkin.

För att du ska få en känsla för hur språket ser ut så kommer här ett exempel, där de fetkursiva orden, samt möjligheten till den korta beskrivningen på raden under scenario, tillhör Gherkin:

Scenario: Duplicate email

Where someone tries to create an account for an email address that already exists.

Given I have chosen to sign up

But I enter an email address that has already registered

Then I should be told that the email is already registered

And I should be offered the option to recover my password


plant, fruit, food, green, produce, vegetable, fresh, kitchen, gourd, eating, vegetables, cucumber, cucurbita, cucumbers, gherkin, preparations, flowering plant, pickled cucumber, ensiling cucumbers, mizeria, land plant, cucumber gourd and melon family, summer squash, Free Images In PxHere


Godbitar jag hittat

För att komma in i testskrivandet lite snabbare så läste jag The Cucumber Book - Behaviour-Driven Development for Testers and Developers. Här nedan kommer de partier jag markerat som "kom ihåg" under läsning.




Readability

When you're writing Cucumber features, make readability your main goal. Otherwise, a reader can easily feel more like they're reading a computer program than a specification document, which is something we want you to try to avoid at all costs. After all, if your features aren't easy for nonprogrammers to read, you might as well just be writing your tests in plain old Ruby code. The real key to expressive scenarios is having a healthy vocabulary of domain language to use to express your requirements. That said, using only the basic set of Gherkin keywords can often make your features repetitive, making them cluttered and awkward to read. By the end of this chapter you'll know everything there is to know about Gherkin's syntax, giving you all the tools you need to write clear, readable Cubumber acceptance tests.

System tests Vs unit tests

It's also worth thinking about whether some of the behavior you've specified in Cucumber scenarios could be pushed down and expressed in fast unit tests instead. Teams that enthusiastically embrace Cucumber sometimes forget to write unit tests as well and rely too much on slow integration tests for feedback. Try to think of your Cucumber scenarios as broad brush strokes that communicate the general behavior of the code to the business, but still try to get as good a coverage as you can from fast unit tests. Help make this happen by having testers and programmers work in pairs when implementing Cucumber scenarios. This pair can make good decisions about whether a piece of behavior necessarily needs to be implemented in a slow end-to-end Cucumber scenario and drive out the behavior using a fast unit test instead.

Överflödiga detaljer

Nedanstående test tas upp som ett exempel på ett test som innehåller alldeles för mycket detaljer på fel nivå.

Ett scenario för en e-postklient på webben:

Scenario: Check inbox
Given a User "Dave" with password "password"
And a User "Sue" with password "secret"
And an email to "Dave" from "Sue"
When I sign in as "Dave" with password "password"
Then I should see 1 email from "Sue" in my inbox

Användarnamnen är användbara, eftersom de är viktiga beståndsdelar i scenariot, men lösenorden är bara brus, de har inget att göra med det som testas och gör testet svårare att läsa. Till exempel så har Sue ett annat lösenord än Dave, vilket kan leda till att du som läsare av testet börjar fundera över om den delen är relevant och tappar då fokus från scenariots huvudsakliga mening, dvs: att testa att Dave kan se Sues email.

Lösenorden är alltså överflödiga detaljer (incidental details), detaljer som nämns i scenariot, men som saknar relevans för scenariots uppgift. 

Här är testet utan lösenord:

Scenario: Check inbox
Given a User "Dave"
And a User "Sue"
And an email to "Dave" from "Sue"
When I sign in as "Dave"
Then I should see 1 email from "Sue" in my inbox

En klar förbättring, mer lättläst och testets betydelse framträder tydligare. Ännu mer brus kan tas bort:

Scenario: Check inbox
Given I have received an email from "Sue"
When I sign in
Then I should see 1 email from "Sue" in my inbox

Nu är det ett koncist trestegs-scenario, som också är lättare att underhålla. Om användarautentiseringen måste ändras, så påverkar det inte själva testet utan bara koden bakom. 

When Cucumbers Go Bad: Imperative Steps

In computer programming, there are two contrasting styles for expressing the instructions you give to a computer to make it do something for you. These styles are called imperative programming and declarative programming.

Imperative programming means using a sequence of commands for the computer to perform in a particular order. Ruby is an example of an imperative language: you write a program as a series of statements that Ruby runs one at a time. 
A declarative program tells the computer what it should do without prescribing precisely how to do it. CSS is an example of a declarative language: you tell the computer what the various elements on a web page should look like, and you leave it to take care of the rest.

Exempel i imperativ stil:

Scenario: Redirect user to originally requested page after logging in
Given a User "dave" exists with password "secret"
And I am not logged in
When I navigate to the home page
Then I am redirected to the login form
When I fill in "Username" with "dave"
And I fill in "Password" with "secret"
And I press "Login"
Then I should be on the home page

Enligt författaren så kan man argumentera att ovanstående testexempel har en del fördelar. Men han menar på att man snart kommer drabbas av problem med test som lätt går sönder och uttråkade intressenter, t ex produktägaren. Test som skrivs på den stilen blir brusiga, långa, tråkiga att läsa och går lätt sönder. Till exempel en så liten ändring som en omdöpning av knappen från "Login" till "Log in" får testet att gå sönder.

Men det värsta är att språket inte tillhör den egentliga problemdomänen, utan blir mer lågnivå-språk med ord som "fill in" och "press", vilka tillhör gui-domänen.

Exemplet i deklarativ stil:

Scenario: Redirect user to originally requested page after logging in
Given I am an unauthenticated User
When I attempt to view som restriced content
Then I am shown a login form
When I authenticate with valid credentials
Then I should be shown the restricted content

Författaren skriver att det snygga med detta är att testet inte kopplas till en specifik implementation av användargränssnittet. Samma scenario kan användas för en desktop-app som en mobil-app.
Orden som används (unauthenticated, restricted, credentials) är förståeliga för en intressent som håller på med säkerhet.

It's true that using declarative style will mean you have to write more step definitions, but you can keep the code in those step definitions short and easy to maintain by pushing the actual work off into helper methods in your support code.

onsdag 5 januari 2022

DevOps i 40-talets kolgruvor

Grundtankarna i DevOps inget nytt
Boken DevOps Paradox - The truth about DevOps by the people on the front line av Viktor Farcic är en samling intervjuer med framträdande personer inom DevOps-rörelsen, där de får möjlighet att beskriva hur de definierar DevOps och deras tankar runt det, eftersom DevOps inte är en väldefinierad process enligt Victor:

The thing is, if there's anything that my years of working in the field have taught me, it's that DevOps is not a well-defined process. There is no set of rules that must be followed. As I discovered in my journey, and as you'll read in these pages, it's even questionable whether there is such a thing as a "DevOps department" or a "DevOps engineer". This ambiguity is exactly why DevOps is so fascinating to me, and I hope to you, the reader, as well.
En av personerna som intervjuas är Kevin Behr, som i sin intervju lyfter att DevOps-tänket med gemensamt mål, samarbete över gränser, kontinuerligt experimenterande och lärande användes naturligt som en "överlevnadsinstinkt" dolt nere i kolgruvorna på 40-talet. Nedan är en översättning av exemplet han tar upp i intervjun ihopbakat med lite av det han tar upp i sin dragning First In Last Out - devops roots in coal mining - Kevin Behr - devopsdays Pittsburgh 2014


Sociologer till kolgruvorna
Efter andra världskriget behövde kolproduktionen i Storbritannien öka som ett led i att snabba på återuppbyggandet av landet efter all förstörelse från kriget. Det låg alltså i nationens intresse att kolgruvornas produktion maximerades. För att uppnå detta anställde regeringen två sociologer, Eric Trist och Elliott Jacques, för att de skulle undersöka gruvorna som ett led i att se vilka som var mest produktiva och vad som gjorde att de var det.

Trist och Jacques upptäckte att alla lågproducerande gruvor hade en hög grad av automatisering, men att automatiseringen inte uppnådde förväntad produktivitetshöjning.

Vad funkar bäst? Team work!
Bland de många olika typerna av gruvdrifter hittade de en design som verkligen särskiljde sig, en design som hade flera gånger högre kolproduktion än de andra. Utöver hög produktion så hade den även signifikant färre skador och en mycket stark lagkänsla!

En annan skillnad de upptäckte var att arbetarna kom till jobbet som de skulle, vilket var en aning udda, för i andra gruvor var som regel 30% av arbetsstyrkan borta. Att jobba i kolgruva var farligt och det fanns många andra jobb i efterkrigstidens Storbritannien.

För att få reda på orsaken till arbetarnas höga närvaro i de högproducerande gruvorna så pratade Trist och Jacques med arbetarna när de kom tillbaka efter sina skift, men det gav inga ledtrådar till vad som kunde vara annorlunda. Så de började följa med arbetarna ner i gruvorna.

Embed from Getty Images
circa 1955: Welsh miners at work in a coal mine.

Självorganisering
Ovan jord så samlade skiftledaren alla arbetarna och gick igenom vad de förväntades göra. Men sen, väl nere i gruvan så märkte de direkt en skillnad: gruppen demokratiserade arbetet. De fokuserade på hela uppgiften, vad de skulle åstadkomma som arbetslag, istället för "jag fokuserar på mitt så gör du ditt".

De pratade om vad som skulle göras och delade upp arbetet mellan sig på ett lämpligt sätt, t ex "Vem drack inte igår? Ok, du får hantera sprängmedlen idag." Vem håller koll på säkerheten? Vem kör borren? De var självorganiserade och självreglerade.

Samtidigt prioriterade de att lära varandra sina uppgifter. På så sätt påverkades arbetsgruppens insats mindre en dag då någon hade ont eller kanske var tankspridd på grund av nåt som hänt i familjen så att personen inte klarade av sina vanliga uppgifter. Det var heller inte helt lätt att ta sig upp ur gruvan om nån blev allvarligt skadad under arbetet, därför behövde flera känna till hur man manövrerade de fordon och maskiner som behövdes för att ta sig ut.

Pareto-principen vid kunskapsspridning
Wikipedia beskriver Paretoprincipen såhär:
Paretoprincipen är en matematisk fördelning enligt vilken 20 procent av orsakerna ofta står för 80 procent av verkan; den kallas ibland även 80/20-regeln. Vilfredo Pareto visade att 20 procent av den italienska befolkningen innehade 80 procent av egendomen och denna observation har av andra senare generaliserats.
Inom mjukvaruutveckling verkar nedanstående gälla:
  • 80% av koden kan skrivas på 20% av tiden
  • 20% av koden har 80% av buggarna
  • 20% av funktionaliteten i ett program används 80% av tiden
Kevin Behr teoretiserar att gruvarbetarna utnyttjade Paretoprincipen för sin kunskapsspridning, det vill säga "lär mig 20% av kunskapen som behövs för att utföra din upgift till 80%". 

Om att lära sig varandras uppgifter på det sättet säger han: "And that is what DevOps is!"

Sociotechnical systems (STS)
Utifrån sin forskning angående kolgruvornas effektivitet så var Eric Trist med och myntade begreppet sociotechnical systems, där sociotechnical refererar till kopplingen mellan de sociala och tekniska aspekterna av en organisation eller samhället som helhet. På grund av att de tekniska och de sociala bitarna kan gå in i varandra så mycket, så måste man vid en optimering av en process ta hänsyn till båda bitarna (teknisk utveckling och kvalitén på personernas arbetsliv). För optimerar man bara en del så riskerar oväntade effekter från den andra delen att motverka optimeringen.

I kolgruvornas fall var det att man automatiserade gruvorna, men automatiseringen ledde till mer ensamarbete och arbetarnas arbetslivskvalité sjönk, vilket ledde till sämre mående och sämre arbetsmoral. Detta tas upp i podcasten Talking About Organizations avsnitt 34 Sociotechnical Systems – Trist and Bamforth

Vad ta med sig från detta?
Ja, vad man ska dra för lärdom av detta? Kanske att om man är på gång att införa DevOps på arbetsplatsen inte stirra sig blind på processerna och verktygen för automatisering av kontinuerlig integration/installation och automatiserade tester utan även ha fokus på det sociala samarbetet?

lördag 30 oktober 2021

Blazor gotcha: Use the @key attribute when visibility of list items can be toggled

Finding the "bug"

We're building a Blazor web from scratch for the first time in a project at work. I like it and we've been able to go pretty fast although it's a new framework for all the devs in the team. But we ran into a strange behavior that looked like a bug.

In the web app a user can add locomotives and wagons to a list to create a train. Each of the vehicles in the list is represented of a header and a body, where the body can be collapsed or expanded.

User input for each vehicle is validated after entry. When a field is invalid a red frame is shown around the field and a validation error message is shown beneath it.

The strange behavior appeared when the body for one vehicle was expanded at the same time as the body for another vehicle was collapsed. When the use entered an invalid value in a field for one of the vehicles, the field for the other vehicle was marked as erroneous!

Reporting the "bug"

I recreated the strange behavior in a minimal project and reported it as a bug in Blazor: Input validation status gets mixed up when toggling content

After a few days I got the reponse:

Thanks for contacting us. It looks like you're missing the @key attribute for the elements which are rendered in a loop. You can learn more about this from https://docs.microsoft.com/en-us/aspnet/core/blazor/components/?view=aspnetcore-6.0#use-key-to-control-the-preservation-of-elements-and-components

The linked page says: 

The mapping process of elements or components to a collection can be controlled with the @key directive attribute. Use of @key guarantees the preservation of elements or components based on the key's value. 

It can be used like this:

<ol>
    @foreach (var person in people)
    {
        <li>
            <Details @key="person" Data="@person.Data" />
        </li>
    }
</ol>

Not seen in any material

I dont't remember seeing this in any Blazor material I've studied so far (pluralsight.com and the book "Blazor in Action"), so if you're going to use Blazor and create something with similar behavior, keep this post in mind! :)

fredag 18 juni 2021

Write a ray tracer guided by Jamis Buck's test suite

Background

Having seen people write their own ray tracers, I've been curious about writing my own. And for a while I also believed I just could sit down and write one, without any help, until I tried. At least I failed fast :)

Fast forward a few years to the moment when I listened to the podcast Developer On Fire, where the interviewer asks the interviewee for book recommendations and the book The Ray Tracer Challenge - A Test-Driven Guide to Your First 3D renderer by Jamis Buck is mentioned. I bought it and started coding.


About the book
The book explains the theory you need and contains unit tests in Gherkin, which means that you can translate them to whichever programming language you want to use. 
Here's an example of a test that subtracts a point from another, which should result in a vector:


I used C# and NUnit, which made my test implementation look like this:


The algorithms that make the tests pass are written in pseudocode, so you have to translate them as well.

What I learned
Test first
I really liked the test first way of coding. It catched errors early which made it easier to spot and correct the bugs. It was good to build up a safety net of tests, because the code got pretty math intense and would be pretty hard to debug without them.

Funny / not funny
The fun part was the coding and to see the resulting images. But creating sceneries and trying out different settings was not that fun, which makes it pretty useless to have my own ray tracer to play around with...

Recreational coding
Jamis Buck has also written a book about how to generate mazes, something he did when recovering from a burn out. He's sharing that story in the pod Corecursive.

Examples of created images

Here's two examples of images I created. 

Snowflakes
This is supposed to look like falling snowflakes. I made it after learning how to create cylinders and cones and how to group simple shapes together.



The making of a kitchen table

Here's after learning to do cubes and planes and manipulate them, like scaling in different directions, move them and give them color and patterns. Also tried to do a kitchen lamp, but found out that the shadow logic was too simple so that a transparent object shadows as much as an opaque object.

Yes, I had at hard time positioning the table legs :)


The code

It took me quite a while to finish the book. The commit history shows that I began in June 2019 and finished in June 2021. I worked with it in bursts and often had long periods of inactivity.

I skipped the code for matrix manipulation, I used the MathNet.Numerics nuget package instead to faster advance to the chapters that resulted in images.

My github repo for this project.

When searching for The ray tracer challenge at github, I get 254 repo hits in 10 languages, where the most are in Rust (51), C++ (48), C# (32) and Go (17).

After finishing the book I also noticed that people have posted their learning journey on youtube, like this playlist.

söndag 25 april 2021

A SourceTree lover sees Visual Studio catching up

Background

This was supposed to be a post about features that I find important for the daily work I do that the git gui SourceTree has and that Visual Studio's git tool lacks. But instead I learned that Visual Studio is catching up with its Visual Studio 2019 16.10 Preview 2.1 release!

File change preview for historic commits

Navigating the commit history and looking at file changes in Visual Studio is a pain, but today I downloaded Visual Studio 2019 16.10 Preview 2.1 and explored the news in its git tool. Looking at changes in historic commits is no longer a pain!

I also learned that Visual Studio can show diffs as inline or side-by-side.


SourceTree shows all branches in history

In SourceTree you see ALL branches by default, which is the way I like it because I get the full latest commit history context immediately. This isn't possible in Visual Studio, you have to select the branch that has the latest commit to be able to see the history for all branches.


If you ever would like to not see all branches in SourceTree, you can easily turn it off by selecting Current Branch in the dropdown, like this.


To show all branches is a feature under review by Microsoft 
https://developercommunity.visualstudio.com/t/how-do-i-view-the-history-of-all-branches-in-git/934801

Merges are shown better in SourceTree

I find the branch history tree to be more clear in SourceTree. Compare these two images that pictures a branch branched off of master, and then the branch is merged back to master.

In SourceTree it looks just like that, a branch going out from master and then coming back to master.


In Visual Studio it looks like a branch has been branched off from master, but then it looks like master has been merged to the branch!? When merging, the merge commit has two parents instead of one. There is a primary parent (the branch merged to) and a secondary parent (the branch merged from) and VS seems to mix them up.


I added a ticket regarding this.

But the image below, taken from this ticket hints about a rewrite of the the commit history tree visualization in VS. No merge is shown, but the tree looks different, and hopefully it will be easier to follow.



SourceTree auto-adds commits message for merge with conflicts

When doing a merge and the merge results in conflicts, a commit message like this the one below is added automatically by SourceTree. Visual Studio adds nothing. 
Merged ‘master’ into 'a_feature_branch'. Conflicts: # Foo.h # Bar.cpp

To be able to see which files that have had conflicts can be of help when you know that a feature has been added in a file, but that feature suddenly is gone or is buggy, because it probably disappeared in a manual merge conflict resolution that went wrong.

This also seems to be a feature under review.

In SourceTree you can pull a branch that isn't currently active

Yes, you can, and I thought it was something that made my branch handling smoother, but when writing this I can't come up with a scenario where it is needed.

onsdag 3 mars 2021

E-handla kläder med din digitala tvilling


Att e-handla kläder kan vara svårt, bland annat att gissa vilken storlek som passar bäst. Storleksangivelsen ger en fingervisning, men är långt ifrån en sanning om plagget kommer passa dig, eftersom storlekar kan skilja från tillverkare till tillverkare.

Och om du är osäker på storlek så kanske du beställer flera olika storlekar av samma plagg och skickar tillbaka resten. Det är det många som gör. En himla massa paketskickande blir det totalt, vilket är ett slöseri. 

För att lösa en del av den här problematiken så har Knowit skapat tjänsten Zizr, https://zizr.id/, en tjänst där du kan ange vad du köpt och vilken storlek som passade dig. Utifrån dina köp och en massa andra klädköpares köpdata så kommer Zizr kunna hitta andra som har din storlek och därmed kunna ge storleksrekommendationer på kläder som de andra köpt och angett att de passar. 

Dina digitala kroppsstorlekstvillingar behöver inte vara helkroppstvillingar, utan kan vara delkroppstvillingar, eftersom matchningen delas upp i fötter, underkropp och överkropp.

Det här är en existerande tjänst, dock är den än så länge bara i beta-stadie och har samarbete med endast två butiker, Junkyard och Kleins, men planen är såklart att knyta till sig så många butiker som möjligt.

Jag har skapat konto och skummat de två klädbutikerna. Än så länge har det inte blivit nåt köp, men jag gillar idén skarpt! Konceptet digitala tvillingar känns underutnyttjat, det är ett kraftfullt verktyg som skulle kunna användas för så mycket mer. Men såklart, det är inte helt oproblematiskt med att dela med sig av sin personliga data inom alla områden.

Här kan du titta på en presentation om hela utvecklingsresan av Zizr.