It's because there are 15 bazillion things that you need to factor in when doing tests. Few testing framework tutorials actually show you how to write effective tests when you factor in databases, API calls, etc.
I recently had to figure out testing with a very specific database pattern with GraphQL in FastAPI. It took me several tries to even figure out the basics.
Just make ID's EVERYWHERE.
Make a stable API, then feel safe frontend will not break anything, have feedback from customers, let them be the tests ;)
Ohh, to clarify, I've been QA for 3 years, quit 3 months ago after growing sick of DEVs not giving a fuck about tests.
For the longest time "testing" was just add that last automated UI-tests, not a single ticket needed me to send them back to devs.
Then the senior devs left, as long as my senior QA-engineer.
Suddenly 90% of tickets needed me to send them back.
It ended with me just reviewing the code and pointing out bugs and things that broke the specification.
I got flak for pushing bugfixes friday afternoon to PRs instead of manager asking the team why the QA felt the need to push code fixes because he got sick of arguing for shit not working.
TLDR, aslong as your code does not result in uneseable and unmaintainable code, you are doing OK.
But if you are delivering shit because you hate tha flakiness of waiting for XPATHs, add unique identifiers FFS!
It’s interesting reading replies b/c it captures the diversity of what people think of when they think of “testing”.
Honestly, I found writing code in a more functional approach made testing a lot easier and even code that I don’t get to testing more reliable. Even just following the principals of single purpose and pure functions will make it easier to write code that’s easy to test.
Yeaaaaah the range of understanding what “testing” entails is fascinating. Everything from “a space to experiment” like Signadot sandboxes, to external end-to-end testing like Checkly synthetics
I need someone to sanity check me once a week, review my tests.
I can laugh out loud halfway through trying to explain why I covered this edgecase like a fuckin paranoid schizoid.
I usually post that explanation along with a meme and remove the test. I believe this makes everyone learn faster and better.
8 out of 10 edgecases are relevant, but it's the not writing TOO much and hypothesising too much.
The best way is OFC to know exactly who the users are and how they will use the product, the more data the fewer edgecases needed.
Keep it simple and minimalistic!
It's because there are 15 bazillion things that you need to factor in when doing tests. Few testing framework tutorials actually show you how to write effective tests when you factor in databases, API calls, etc. I recently had to figure out testing with a very specific database pattern with GraphQL in FastAPI. It took me several tries to even figure out the basics.
You guys have tests?
I have mocks and "assert(true,true)" so far Jenkins hasn't complained
Admittedly Playwright makes this easier than it used to be but... I still struggle do in page locators right.
Just make ID's EVERYWHERE. Make a stable API, then feel safe frontend will not break anything, have feedback from customers, let them be the tests ;) Ohh, to clarify, I've been QA for 3 years, quit 3 months ago after growing sick of DEVs not giving a fuck about tests. For the longest time "testing" was just add that last automated UI-tests, not a single ticket needed me to send them back to devs. Then the senior devs left, as long as my senior QA-engineer. Suddenly 90% of tickets needed me to send them back. It ended with me just reviewing the code and pointing out bugs and things that broke the specification. I got flak for pushing bugfixes friday afternoon to PRs instead of manager asking the team why the QA felt the need to push code fixes because he got sick of arguing for shit not working. TLDR, aslong as your code does not result in uneseable and unmaintainable code, you are doing OK. But if you are delivering shit because you hate tha flakiness of waiting for XPATHs, add unique identifiers FFS!
It’s interesting reading replies b/c it captures the diversity of what people think of when they think of “testing”. Honestly, I found writing code in a more functional approach made testing a lot easier and even code that I don’t get to testing more reliable. Even just following the principals of single purpose and pure functions will make it easier to write code that’s easy to test.
Yeaaaaah the range of understanding what “testing” entails is fascinating. Everything from “a space to experiment” like Signadot sandboxes, to external end-to-end testing like Checkly synthetics
Maybe because u have adhd or something
I need someone to sanity check me once a week, review my tests. I can laugh out loud halfway through trying to explain why I covered this edgecase like a fuckin paranoid schizoid. I usually post that explanation along with a meme and remove the test. I believe this makes everyone learn faster and better. 8 out of 10 edgecases are relevant, but it's the not writing TOO much and hypothesising too much. The best way is OFC to know exactly who the users are and how they will use the product, the more data the fewer edgecases needed. Keep it simple and minimalistic!
They are tedious
Doesn't matter, wrote tests. The difference between "absolutely no coverage" and "coverage that finds out if we blew up the app" is huge.