So, I built a beautiful website that searches the web and uses “natural language processing” to generate synonyms and phrases. It finds available domain names when the one you want is not available. (besta.domains)
But, I realized it’s very difficult to run a business (actually getting someone to pay for it). Ok, I’ll just continue this as a side project. So, I started applying for jobs, and doing interviews. Meanwhile, I was still tweaking and developing my app. One day, I go to use it online, and it is broken. Embarrassing! Wonder how many people saw it like this?!
I was pushing changes without adequately testing them. Strange thing is I remember testing in production, clicking around, and it looking good. Maybe I forgot to clear cache. NO. Update: the problem only showed up the second time the page was viewed, not the first. WTF? Guess I only checked that page one time, and it looked good.
The problem was a very technical server-side-rendering issue. I was using "Styled Components", but they take a bit more setup for SSR (server-side-rendering). Instructions how to properly use them with NextJS linked the bottom. The problem got out of hand because I was spreading myself too thin, trying to publish too fast. I should have spent more time testing and debugging.
How to make sure this never happens again?
Slow down. Simplify. Leave lots of time for testing.
Set up automated integration/end-to-end testing. Unit tests are not enough! In this case, all the content and functionality was there, but because of a “server-side-rendering” bug, the HTML/CSS was broken sometimes. With “functional” (or “end-to-end”) testing, it’s possible to catch that. Still, you have to program the test to check for layout issues. It should be run by a separate server which runs on an interval and alerts you when there’s a problem. This will let you fix the issue as soon as one comes up, in case the site breaks sometime in the future.
The testing needs to be part of the “continuous integration” process. It must pass before the code is allowed to go into production. This should be a required step in any production workflow, in any company, any team, no matter how big or small. This way, if there is an issue with new code, it can be caught before the code is deployed to production. Unit tests only check individual pieces. Testing the final product is actually more important.
ChecklyHQ to the rescue!
Checkly is an amazing and FREE service which lets you test any website on an interval (as often as every 5 minutes), from multiple locations in the world. It has an interface for checking API data also, including response time.
It’s easy to make it part of the CI (continuous integration) or CD (continuous delivery)! You can program a quick Bash script into whatever build process you use, on the front or back end. But scroll down, theres more…
It’s even easier when using Github with a pre-configured CI/CD hosting service like Vercel/Netlify/Heroku, or a custom configured Travis/Jenkins/etc. process which deploys a version of the website for each Git branch. With each new deployment, the temporary preview subdomain is passed to Github and then to Checkly via an environment variable.
In the “SCRIPT” tab, write your Puppeteer script. Mention process.env.ENVIRONMENT_URL to refer to this auto-generated subdomain:
In the “CI/CD” tab, simply link the GitHub repo:
Warning! Remember to test for style/layout - not just content/functionality! In case CSS breaks like it did for me. ;)
Another warning! Do not ignore any development environment error. It may cause issues in production! This was also the case with me. EsLint will not always catch everything!
Lessons to remember:
A feature is not finished until it is tested - thoroughly, manually, and automatically, and this testing is part of a continuous integration process which will not let you deploy until all the checks pass.
Don’t assume a program will function predictably. There are always unexpected things that will go wrong - sooner or later. Especially on the web, with multiple devices. There are so many edge cases! Even if it looks good to the developer, the end user may have a different experience. It’s important to automate tests for multiple devices and use cases.
Related links:
https://besta.domains <— the app
https://paulshorey.com <— the author
https://checklyhq.com <— awesome live functional testing for development/preview/staging/production
https://www.browserstack.com <— important (also freemium) tool to test your app in any browser or device
https://jestjs.io/docs/en/getting-started <— Jest unit-testing framework for React
https://dev.to/toomuchdesign/dom-testing-next-js-applications-46ke <— great article about “integration” testing React apps in NextJS
https://dev.to/aprietof/nextjs--styled-components-the-really-simple-guide----101c <- step-by-step how to use Styled-Components with NextJS SSR/SSG (IMPORTANT! the "styled-components" babel plugin must be the very last thing in the .babelrc plugins list! This was my problem. Always something seemingly insignificant with programming!)
Any advice, ideas, favorite tools or techniques?
Please comment below, or message me (Paul Shorey). Thank you!
Top comments (0)