Studying in the U.S. broadened my worldview and sparked a love for diversity and exploration. I’ve since lived in Michigan, Warsaw, and London—and traveled to 60+ countries.
Full-Stack Testing
My experience includes frontend testing of user interfaces and backend testing of services, data handling, and application logic.​​​​
It’s more of a personal collection—random things I come across, resources worth remembering, and thoughts I might want to come back to later. Just a place to keep track of it all.
Hard-coded test data works for small demos, but it quickly becomes a problem in real test suites. Using the same values repeatedly creates unrealistic scenarios and can cause conflicts when tests create or manipulate data. A better approach is to generate dynamic test data using a library like Faker . Why Hard-Coded Test Data Is a Problem Example of common hardcoded test data: "Test article" "John Doe" "Lorem ipsum" Problems with this approach: Tests always use the same valu
UI automation is naturally flaky. Even well-written tests may occasionally fail due to timing issues, environment instability, or application state problems. A test might: pass 10 times fail once pass again on the next run This creates noise in CI pipelines and can break the expectation of a 100% passing test suite . Cypress provides a built-in retry mechanism that automatically reruns failed tests before marking them as failed. Why Retries Exist Retries help stabilize test
Hardcoding credentials, API URLs, or environment-specific values in tests is not ideal.It makes tests harder to maintain and can expose sensitive information. Cypress provides several ways to manage environment variables , allowing tests to run across different environments (dev, QA, staging, production) without changing the test code. This page is a reference for the most common approaches. Why Use Environment Variables? Environment variables help: Avoid hardcoding credenti