“Do you know what Web Components is? How would you test hundreds of them?” — Sami Ekblad, my supervisor in our interview
That was the beginning of my journey to explore the world of web components. I, myself, was a 22-year-old IT student with no professional experience. And to make it even more interesting, that interview was the first time I heard the term “Web Components.”
Things were rough in the beginning. No one in our company has done this task before, or anyone else publicly. There were no testing guidelines, no formats, no nothing. This was the scopes list I come up with:
- Functionality: Is it working?
- Design: How does it look?
- Compatibility: Does it work on all platforms?
I begin by manually picking some from webcomponents.org and start testing them. Luckily, they feature JSFiddle demo (like this) for previewing components. The downside is that they are available only if the author provides the sample code. Nonetheless, those inline demos are the little sunshine! ☀️
To keep track of the records, I set up a spreadsheet. Everything was manual, the spreadsheet, the writing, and the testing. They were notably time-consuming, but my boss, he believes it’s the way to go before any automation takes place.
With the discovery of webcomponents.org API, I managed to populate my spreadsheet with all the web components there, along with its author, description, etc. Python was my best friend during this time, it’s fast and convenient for making small scripts to work with the API and the spreadsheet. However, the reality kicks in, I still have to test the components manually.
Safari Tech Preview, Chrome Canary, Firefox Nightly, and Opera were the four browsers I used for testing the compatibility, mainly because Web Components standards are always implemented there first before the stable versions acquire them.
For the components that have demos, it was easy. You just copy and paste the Fiddle link to every browser to see if it works, right?
The answer is NO!
Let’s consider one person, who makes 5 web components, and each of them was made differently. Now multiply that one person by a hundred and there you go, hundreds of projects with fat-fingering and typos.
For the components that do not have demos, I need to understand what they are for, how they were created and how I should use them in order to write a sample code that works. It was a nightmare to deal with hundreds of code writing styles.
In the end, I’m not even sure if that component does not function because of the element or because of my code.
As I become more familiar, things have processed much faster. I was able to analyze a component quickly.
After 5 months, I finally accumulated 696 tested elements (I will feature these statistics in another story).
“How did you do it?”
Well, the whole process was a trial and error. Experiencing is the answer.
“How do I feel after testing that much components?”
Tired but also proud, I did not have any prior experience to web components, testing or even coding before doing these. And the best thing about it? The records are public.
“Seriously, everything is public?”
Yes! Every working component that I have tested is included in Vaadin Directory. They come alone with a personal review and a demo sample, which I made in CodePen & JSFiddle.
Make sure you check it out!
“Am I the one who tested the most number of web components in the world?”
“Do I understand Web Components the best now?”
Definitely not, there are a lot of people who comprehend so much more of this beautiful standard, and I am merely a tester.
“What is the point of this story?”
It’s something I’ve been wanting to publish on Medium for a while now, I started testing one year ago. The journey was amazing to me, and I hope you might learn something from it.
Feel free to ask me anything regarding my journey or about Web Components. Thanks for reading!