Thinking about JS front-end testing

Diede Gulpers — Mon, 28 Aug 2023 08:07:43 +0000

Currently I am working on a Vue component library which can use some testing. Since Vue components always form a wonderful mix of JS, HTML and CSS it is harder to me to think about testing them the way I would in PHP.

Because in PHP I often can use a very clear cut setup of testing the public functions of a class and can easily mock out the dependecies by injections. I can quite easily hold on to the concept of Unit testing as a basis for my tests.

In Vue components I believe all I should do is consider all my work to be intergration testing rather then unit testing. My main arguments for this are:

My templating logic, like the v-if and v-for, heavily define the logical paths and can't be turned into seperate units/functions.
My JS logic should not be turned into seperate files or composables just for testing purposes if it is more logical or practical to keep it in the component. what I consider logical or practical reasons to seperate code is when you want to use it in at least two places or when you can keep a better overview of what is happing in the component.

To me it becomes easier to reason about all my components as intergration tests, that at the very least combine three languages and in most cases also include dependencies in JS in the form of packages, composables or child components.

This thinking makes it easier for me to review my code prior to writing tests. I now skim them for what I would consider a Unit and then write a few tests per Unit in a intregration testsuite instead of pulling apart a nice component and testing every function.
What I consider a Unit is more then the specific function or () => we use in JS. Every logical fork can be considered a Unit and I just make a educated guess about which of those forks are important. If I have a v-if on a prop boolean that shows or hides text I tend not to test it, because by reading the code I am already a 100% certain it will work. But if I have a v-if that if the boolean is true is depended on other props to exist to show an output I am more likely to test it.
Basically I try to look for "meaningful intersections" within all the logical paths that exist in my code.

Does my reasoning make sense to you? Or do you believe I am wrong in thinking that components should always be viewed as intergration tests? I would like to hear a different take on the topic.

Shy-phen! the best named HTML character entity!

Diede Gulpers — Wed, 05 Apr 2023 12:31:05 +0000

This is a celebration post of the seldomly seen HTML character entity that should get more appreciation: the shy-phen. Its not for its function that we celebrate it, but for its perfectly fitting Entity encoding.

I was working on a Dutch in-depth blog post about Accessibility and I wanted to hyphenate words only once the screen would become to small.

Before celebrating the shy-phen lets first talk about what we are looking at here. We are looking at a HTML character entity reference. Which is a wild ride on its own.

The references have come to exist do to a simple problem: we have to many characters in different languages and different fields of expertise to fit them all nicely on a keyboard.

That's why over time we have come up with many standards that describe sets of characters and how to encode them. The leading standard for describing characters right now is Unicode, which describes 149,186 unique characters and has 1177 new characters on its for ever growing waiting list.

Currently HTML supports at least 2231 by name of these characters, although you do best to check if any character you want to use actually is supported.

See how I use, "by name"? This has everything to do with the fact that we have 3,75 ways to write down a HTML entity reference in HTML! We can target them as numeric character reference, a hexadecimal numeric character reference, a hexadecimal numeric character reference without leading zero's (I am counting it as 0,5 way) and a character entity reference, and some character entities may omit the ; (counting it as 0,25 way).

Lets take the yen ¥ as an example we can write it as:

&#165; 
&#x00A5; 
&#xA5; 
&yen;  
&yen

all of them are valid.

So, why so many notations? Both the hexadecimal and decimal notation now work in HTML but older versions of HTML only supported decimal notation (Unicode itself seems to have used hexadecimal notation since version 1.0.0).

The character entity notation is mentioned in html 4.0 as being a way to more easily remember encodings by name then by numbers. It seems to be the main introduction to the named entities and it started out with 96 entities.

Its current list concluded it was no longer desirable to keep adding new entities, having grown to 2231 entities it is considered it will introduce more risks and little value.

Now why would we celebrate the shy-phen? It has everything to do with its entity name and its function. The name is  and its function is to only show itself once really needed and else it hides. So in other words, its a very shy tag!!!.

When we consider its function, its terrible to use. You need to put in words to break them up on locations you want to allow it to be broken up. So far so good.
However you don't want to add this hidden hyphenation in every word, because it would make the text hard to read so ideally you only implement on words you know to be to long to render in a single line, so that they break up nicely on smaller screens. With the advents of folding phones and phones and screens having different pixel densities it is quite up in the air if your shy hyphen will ever come out to play.

Anywho, here is my love post about a very shy hyphen. Let me know if you have any unicode or html entity you feel strongly about :D.

Forem: Diede Gulpers

Thinking about JS front-end testing

Shy-phen! the best named HTML character entity!