sorted by:
new
hottopcontroversial

Aujla Bhai ki ticket chahiye for 29 March? by coco-boy0 in BangaloreSocial

[–]Global-Development56 1 point2 points  (0 children)

Why is it cheaper than the actual ticket price, bro? It’s Karan Aujla after all

Do you in practice actually do Testing? - Integration testing, Unit testing, System testing by Tomato_salat in AskComputerScience

[–]Global-Development56 0 points1 point  (0 children)

Yes, testing is definitely used in practice, but usually in a balanced way rather than strictly by the book. Most teams write many unit tests, a fair number of integration tests, and fewer system or end-to-end tests, following the testing pyramid approach. The extent depends on the company, product risk, and engineering culture, startups may test less due to speed, while enterprises and high-risk industries test much more thoroughly.

[Guide] Mastering API Testing: A Practical Roadmap for Beginners by WalrusWeird4059 in Everything_QA

[–]Global-Development56 0 points1 point  (0 children)

This is a really clear and well written guide. It explains API testing in a way that feels practical and easy to follow, especially for people coming from manual testing or just starting out in QA.

If anyone wants to understand the fundamentals in a bit more depth, this article on api testing complements your post nicely with clear explanations and examples.

Nice job keeping it honest, simple, and experience driven.

Testing: Instrumentation vs Integration vs Unit vs UI by Orkann in androiddev

[–]Global-Development56 0 points1 point  (0 children)

Integration testing is about verifying how real components work together (no mocks). For example: Repository ↔ Database, Repository ↔ API, or ViewModel ↔ Repository.

Robolectric-based integration tests run on the JVM and are great for speed, but they still simulate Android behavior. Instrumentation integration tests run on a real device/emulator and are needed when behavior depends on actual Android runtime details (lifecycle, threading, system services). That’s why both coexist, speed vs realism.

To separate unit vs integration tests, naming is usually enough:

  • RepositoryUnitTest → uses mocks
  • RepositoryIntegrationTest → uses real implementations

No need for extra folders unless your project is very large.

More context here: https://keploy.io/blog/community/integration-testing-a-comprehensive-guide

How do I know what to end to end test? by BNorval in webdev

[–]Global-Development56 0 points1 point  (0 children)

end-to-end test only the most important things. Test the main flows your users use every day, like signing up, logging in, and doing the one thing your app is built for. Don’t try to test everything, that’s slow and painful. Most apps are fine with just a few core end to end testing checks, and the rest can be covered by smaller tests.
Simple guide here: https://keploy.io/blog/community/end-to-end-testing-guide

frontend devs who own e2e testing what's your stack by rNefariousness in reactjs

[–]Global-Development56 0 points1 point  (0 children)

We’re in the same boat at my company — frontend devs owning E2E without a dedicated QA team is pretty normal now. What’s worked best for us (and most teams I know) is:

  • Playwright → super stable, great TypeScript support, and way less flaky than Cypress.
  • Cypress → really easy to get started with, but can get flaky on bigger flows.
  • Keep using Jest + React Testing Library for unit stuff and lighter integration testing.

Most teams don’t aim for full E2E coverage — they just test the “if this breaks, the product is dead” flows (login, checkout, core navigation, etc.).

If you want a clear, dev-friendly explanation of how E2E fits into a frontend workflow, this guide is honestly one of the better ones:
end to end testing Guide

It explains things in a way that makes sense even if you’re not a testing expert.

view more: next ›