DEV Community: jozsefDevs

🌶️ Hot tip - Use snapshots in React Testing Library to debug faster ⚙️

jozsefDevs — Mon, 23 Jan 2023 21:06:53 +0000

So you have this test that is already spitting out something big and complex to DOM and it's failing to find the expected element. You see the usual error message TestingLibraryElementError: Unable to find an element with the text: ... and absolutely have no idea where things might have gone wrong. Inline errors are nice, however, you can't see the problem. 🙈

🍀 To solve this we will leverage snapshot testing! 🍀

Modify your test to get the container out of render, then make a snapshot with expect(container).toMatchSnapshot() 🪄. Notice, this trick can be applied regardless of the complexity of your test.

Re-run your test you'll see the snapshot file 🎉 (App.test.tsx.snap), which is now totally under your control.

You can easily spot the problem and search your way through. It's pretty printed and already formatted as your IDE knows this stuff. Feel free to look around and close/open tags to see what is the actual DOM content at this point of the test.

Okay, we've found the problem, we missed some additional characters inside. Now we can fix our test. We can rerun and see it's all green 💚.

🚨 Also, make sure you remove the *.snap file and the related toMatchSnapshot line to avoid having unexpected snapshot tests later.

💡 This technique is especially useful when your component is rendering a huge markup (maybe a composite component already) and you can't find out why your test is not finding an element.

💡 Also useful to apply this technique if you just want to know the DOM state at a given step. If you are testing a loader with async data, you'll be able to make a snapshot before and after the async data have been loaded.

Let me know if you find this useful 😊

Hungry for more RTL tips 🍽️ ? See my previous post ➡️ Top 3 React Testing Library mistakes I should have spotted earlier 🚀

Happy testing!

Top 3 React Testing Library mistakes I should have spotted earlier 🚀

jozsefDevs — Sat, 17 Dec 2022 20:16:06 +0000

There are a few mistakes that are incredibly easy to make in React Testing Library and I wish I'd watched out for these earlier. Recently I've fixed hundreds of these in a more extensive code base, so just making a remark here. Watch out for these!

1 - Await on synchronous queries

// ❌ Incorrect code ❌
await screen.getByTestId('menu') // check for existence

// ❌ Incorrect code ❌
const banner = await screen.queryByTestId('banner')
expect(banner).not.toBeInDocument() // check for non-existence

Here the problem is that we're awaiting on methods that are synchronous by default.

// ✅ Correct code
screen.getByTestId('menu') // check for existence

// ✅ Correct code
const banner = screen.queryByTestId('banner')
expect(banner).not.toBeInDocument() // check for non-existence

💡 Remember, getBy..., queryBy..., getAllBy..., queryAllBy... methods are synchronous. Meaning they're only useful, if your component already rendered elements you want to find. (Probably not a good idea to use these, if your component is making a network request to get the data and just renders after.)

💡 Check out this related eslint-plugin rule

2 - Not awaiting on asynchronous queries 🙀

This problem is the inverse of the previous one. 🙈

So let's say your component is only rendered after fetching some network data. In this case, synchronous methods are not helping, because they won't wait for the data to be rendered. In these cases you'll need to use findBy.../findAllBy...

However there is a problem with the code below ⬇️

// ❌ Incorrect code ❌
screen.findByTestId('menu') // check for existence

Yep, there is no await used here. This findBy... call gives us back a promise, because it's always async.

// ✅ Correct code
await screen.findByTestId('menu') // check for existence

💡 Please always await findBy..., findAllBy... queries.

💡 Check out this related eslint-plugin rule

As an extra takeaway task, I leave this here for you to find out why this one will always get us fake results. 🙈

// ❌ Incorrect code ❌
expect(screen.findByTestId('menu')) // -> psst.. this will always pass

3 - Using queryBy.. to check existence

Okay, so we can easily decide when to use sync or async methods, but how about this one?

// ❌ Incorrect code ❌
expect(screen.queryByText('A title')).toBeInTheDocument();

As per documentation, queryBy..

returns the matching node for a query, and return null if no elements match. This is useful for asserting an element that is not present.

💡 Please only use queryBy..., queryAllBy... queries when you want to check that an element is NOT present.

💡 Check out this related eslint-plugin rule

// ✅ Correct code
expect(screen.queryByText('A title')).not.toBeInTheDocument()

+1 - Use React Testing Library eslint plugins

You might have noticed already that I've included the related eslint-plugin rules for all the mentioned problems. I love automating rules because they're ensuring good code quality and consistency within the team.

🚨🚨 You must install eslint-plugin-testing-library and eslint-plugin-jest-dom if you're working heavily with RTL in your project.

If you have already a lot of tests (which you should 🙈) eslint won't go easy on you after installing these plugins. However it worth fixing every recommendation it has 💪

Happy testing!

Reference: Common mistakes with React Testing Library

Backup/restore most of your Mac's dev tools easily

jozsefDevs — Sat, 26 Nov 2022 22:00:23 +0000

I was about to make a joke on Twitter the other day, saying how I move to a new Mac is basically about this command:

brew install yarn nvm cowsay fortune tree direnv gh git-lfs imagemagick jq qpdf webp

Because most of the tools I often use (besides VS Code) are living in the terminal installed by brew

That's when I was discovering that brew actually has a subcommand called bundle. 🤯🤯🤯

Basically, it generates a "Brewfile" for you (like your beloved package.json files in node projects), writing out a list of packages (called formulaes here) that you have installed.

All in all, it's a brilliant way to move all your devtools quickly from one Mac to another.

Give it a try!

1️⃣ Generate a Brewfile (acting as your lockfile) with
brew bundle dump

This file is totally human-readable, so when you cat it, you should see something like:

tap "homebrew/bundle"
tap "homebrew/cask"
tap "homebrew/cask-fonts"
tap "homebrew/core"
brew "cowsay"
brew "direnv"
brew "fortune"
brew "imagemagick"
brew "jq"
brew "neovim"
brew "nvm"
brew "qpdf"
brew "ripgrep"
brew "tree"
brew "yarn"
cask "firefox"
cask "font-hack-nerd-font"
cask "iterm2"
cask "signal"

2️⃣ Carry this Brewfile to your other machine, and just type

brew bundle install

It will install all the dependencies listed in your Brewfile.

That's it! 💪

3 killer tools to debug your Monorepos

jozsefDevs — Fri, 15 Jul 2022 14:45:29 +0000

Lately, I've been doing a lot of migration from single repositories to Monorepos. Here are three very handy tools to make these setups debugging easier.

1 - Yarn why / npm ls

If you're using Yarn, this is really useful for checking why a certain dependency is inside your codebase, how it got there and which packages are depending on it.

yarn why react

Official docs on Yarn why here.

If you're not a Yarn user, you can also use the following command:

npm ls

Run this itself to get to know about dependency errors inside your project (marked with red).

Or you can also check how many times a package got involved in your project by just giving the package name as a parameter

npm ls react

Be brave about resolving your dependency hells! 🍀

2 - Tame your TypeScript configs

So let's say we have something like this for the structure for your monorepo:

├─ apps/
│  ├─ frontend/
│  ├─ backend/
├─ packages/
│  ├─ tsconfig/
│  ├─ config/

It could happen that there is a tsconfig.json in your apps/frontend and also apps/backend folders and they're extending a base config from packages/tsconfig.

Also there could be more complex cases, so if you're curious at the end of the day how your final tsconfig.json will look like for a specific project you can do:

tsc -p apps/frontend --showConfig

This is going to print out the whole merged typescript config what the project will use.

Original idea from here, big shout out to Marius. 🎉

I also advise to record this into your root package.json as

"tsconfig:debug:frontend": "tsc -p apps/frontend --showConfig"

to give your team a nifty debug script that they can rely on.

3 - Ace your eslint configs

In my experience eslint configurations can blow up really quickly, especially when you're trying to make sense and merge from two different projects.

🤔 Not sure which plugins/rules are actually being used when you run eslint?

Try this for one of your files:

npx eslint --print-config apps/frontend/what/ever/your/file.ts

This will print out all the rules and plugins being used so you can grasp what's happening under the hood.

Summary

That's it for today, I wish you Happy debugging! 🤘

How to debug artifact passing on Gitlab easily

jozsefDevs — Fri, 29 Apr 2022 12:05:27 +0000

How to debug artifact passing on Gitlab

Lately, I've been working a lot with GitLab pipeline files and I have now a bit more complicated setup than usual. In my case, the middle step is included from another project as a template. I had a nasty bug that from the first step artifacts were never arriving at the last step. However as per Gitlab's docs that should be working by default.

A simplified version of my gitlab-ci.yml. Inspiration from StackOverflow:

image: ubuntu:18.04

stages:
  - test
  - build
  - deploy

test:
  stage: test
  script:
    - echo "test result..." >> test_result.txt
  artifacts:
    paths:
    - "test_result.txt"
    expire_in: 1 day

# runs in stage build
include:
 - project: 'another-project'
   ref: 'master'
   file:
     - '/templates/build.yml' # this creates build_result.txt

# trying to debug if included step can see the artifact from before
included-build:
  script:
    # This is wrong! Overriding the included template's script section
    - cat test_result.txt

# test_result didn't arrive here at all
deploy:
  stage: deploy
  script:
    - cat test_result.txt
    - cat build_result.txt

The Problem

So I wanted to debug why test_result.txt from the first step never arrived at the last stage.

My first thought was I can debug this by adding a script to every step in between to cat test_result.txt right? Nope!

Because the included template also introduces a script section, if I add a script section to included-build the included scripts will be overridden. Thus losing the original behavior.

🔥 Hot tip, you can always validate this by looking through the (View Merged YAML)[https://docs.gitlab.com/ee/ci/pipeline_editor/#view-expanded-configuration] tab. This way you make sure you see everything merged from templates and won't be surprised :).

The solution

I discovered that every job can have a before_script. In my case, this was not used in any steps, so I could use it with confidence. This way I can be sure I don't break any scripts already included.

# trying to debug if included step can see the artifact from before
included-build:
  when: on_success
  before_script:
    # right! Won't change the original behavior of this job
    - cat test_result.txt

So I could add this before_script section to every job in between the first and last step, and this way found the bug easily. Hopefully, this small tip helps you as well.

🔥🔥 Extra hot tip, use the Gitlab Workflow VS Code Extension, it works with on-prem servers as well (not just official gitlab.com projects)!

You can...

follow your latest pipeline without stepping out from your VS Code.
Have CI variable auto-completion.
Review and create merge requests

It just works like a charm, a must-have when working with GitLab.

How to pass Certified Kubernetes Application Developer (CKAD) Exam

jozsefDevs — Fri, 30 Apr 2021 14:28:38 +0000

CKAD is a tough 2-hour long exam focusing only on exercises and challenges to be fixed in a real k8s cluster environment. Only practical questions in a terminal with a short time-frame. Here's some magic how I managed to ace it for the first time.

Why is it so tough?

You have to carry out 19 exercises in 2-hours (yup, roughly 6 mins per challenge). This means you'll have to be fast and on the point. Also you need to complete 66% to pass. To simply put it: Your k8s knowledge has to come from muscle memory. There is no time to read up on forgotten topics.
It's a proctored exam meaning you'll be watched through your webcam however you can't see or hear the proctor. You can have access to the proctor through a chatbox. You can only have 2 Chrome tabs open. First is the exam, second is the official docs. This created an interesting tension for me from the beginning. So be prepared to find your inner peace ☮️

Kubernetes is using a LOT of objects and also has a LOT of commands to really get what you want. So how to make your k8s knowledge as if it were muscle memory? That's where I used...

Anki, anki, anki

Have you ever used flash cards for learning? No? You should give it a try right now! This is my 🪄 secret magic 🪄 to keep up with all types of tech-related knowledge I'm bumping in. Check Anki's website it's completely free. It has a great documentation and also explaining Videos.

Using this tool for me is like defining your own advertisements. When you're binge- watching TV you get a lot of commercials which are simple, short and well-repeated. That's why you can remember them easily after so many years!

Now imagine your life is a movie... Also that you can create your own ads, but the content for these are actually helping you to master new things. Also, this is better than "telly" because you can control when these ads are showing up! So when I'm noticing just a 5 or 10-minute period in my day where I have nothing to do (this could be either; waiting for a bus; waiting for someone; waiting for the build 🤔 etc.) I will review one of my decks on my phone. Because Anki also has apps compatible with all kind of devices with cloud sync. This is a really great way to learn and there are no more excuses such as "I don't have enough time" or "Ohh shoot.. I have my notes on my other device". Check out the docs to find out more.

Getting back to Kubernetes, you don't even need to create your own Deck (set of cards). Because that step usually takes a lot of time before you can actually start learning (revising cards). There is already a shared deck called CKAD Prep exercies. Use it, update or extend it as you discover new things!

Revising these cards will make you remember to the most important commands/switches and concepts which I'm going to note just down below.

Imperative commands, docs, self-checks

As I said you don't have a lot of time to think. So it's better to cover everything you can with imperative commands because they're real time-savers.

Use kubectl run as often as you can. Almost all switches provided with it are pretty useful. Take time to see what are these doing: --annotations, --env, --labels, --requests, --limits, --serviceaccount, --port and --expose
kubectl create is also a key player in this time-saving game.
Combine the run/create command with --dry-run=client -o yaml so you can get a preview what you're about to do. Also, you can pipe this into a yaml file and modify further.
There are several objects which you can't create through imperative commands. This is the point where you need to read carefully the official docs. If you familiarize yourself with the articles there, the quicker you find important pieces like this section on Persistent Volumes or this on multi-container pods. As a general rule of thumb, objects that can't be created with run/create should be copy-pasted out from the docs.
For the sake of the exam don't take too much time in official docs on topics which are not part of the CKAD_Curriculum_V1.20.
Self checking is also important. In the real exam environment you won't see whether you performed one task good or not, you have to check it for yourself. You only see the weight of each task in %. This way you'll be able to see quickly if you have already reached the 66% to pass or not. For example if you created a service containing nginx pods you want to make sure if you do a wget -O- service:80 it works. So prepare to use heavily describe/get/exec and logs to check back your results.

Further helpful resources

Just a list of bookmarks I kept in my Chrome which are contributed to my success in a huge way. You can boost your learning with these big time 🔥

Summary

I hope you find what's written here useful, and it helps you to get a better understanding on your journey. Go && Ace that exam!

I would honour your feedback about this post in the comments section below. ⬇️⬇️⬇️ Feel free to write in case of any questions. You can also ping me on Twitter: @jozsefdevs . Have a wonderful day!

Pancake stack with fixed header and footer

jozsefDevs — Mon, 29 Mar 2021 11:51:21 +0000

Not so long ago on one of my projects my task was to refactor our usual Pancake stack. By this we wanted to achieve better maintainability and also better understanding for newcomers. Here I will demonstrate you the separate stages of the fiddling process and of course the result.

The task at hand

We had in our code base a usual pancake stack with header, content, footer. Let's describe a bit better all the requirements for this layout:

Header and footer should be always visible in viewport.
If we have a lot of content the content area should be scrollable. If we have less content the footer should stay on bottom of the viewport.
Header/footer should be extensible without coding or modifying existing code too much.

So here I show you how it was looking like before the refactor =>

Okay so this solution is just working fine. Also if you check it out on a real mobile device the requirements are still fulfilled. However there are some key problems with it

header and footer height is a fix value (meaning we can't easily extend it)
main element's padding-top and bottom has to know about the height of header and footer. (so heights are actually duplicated in code)
In this example I wrote the value with calc, so calc(50px + 10px) to just highlight that the 10px on the right is the main element's own padding. In the reality this was added together to 60px. So for someone just coming to this code it's really hard to grasp how this height is combined together.

❌ So it's was a nice start, we covered most of the requirements, but fail to fulfil point 3.

Can we make this better?

Of course, we can iterate once more on this layout code. So notice this new version is also working properly on real mobile devices and has a few noticeable changes. Here it comes:

I will refer with my points here to the little number emojis I placed in the CSS code example:

1️⃣ We removed every "dependency" from the main section's CSS. So main currently just sets its own padding, which makes it more maintainable in the future. Also it adheres the Single Responsibility Principle in its own weird frontend way. 🤯
2️⃣ While header/footer height is still fix we are using CSS variables. (Notice that this might be not the best solution for you, if you want IE11 support still...) So a baby step into a more dynamic version, where we can easily handle if the header gets bigger. See points below.
3️⃣ We can do this trick because we create a :before and :after element. Those are having exactly the same height as the header/footer. So this way the content can't go under the real ones because they have their "siblings" underneath.
4️⃣ Here comes the power with CSS variables. Whenever we're adding a new component to the header we just need to change the --header-height variables height properly. Try fiddling around and push the Toggle header! button I've placed there to see how the layout would adjust in case of a new component added. Of course for this we need a little JS code to place .big-header class on the body.

CSS Grid?

Okay so how I went down this path actually... I tried to refactor the initial version to a working CSS Grid solution! That was my motivation to rewrite this layout code in a large SPA. However there were some unexpected hiccups... I will write about that in a follow up post.

Summary

Okay that's it! We just made a more reliable Pancake stack layout and also our code became cleaner and more maintainable.

I would honour your feedback about this post in the comments section below. ⬇️⬇️⬇️ Feel free to write in case of any questions. You can also ping me on Twitter: @jozsefDevs. Have a wonderful day!