Testing is better than data structures and algorithms

Learning how to test (resources and techniques)

• Commenters list classic resources: books on legacy code, TDD, property-based testing, fuzzing, and foundational texts like The Art of Software Testing.
• People recommend behavior-style structuring (“given/when/then”), small focused tests, and avoiding tests that require full environment setup except where necessary.
• Property-based testing and fuzzing are highlighted as powerful, especially for APIs and complex systems. Some also emphasize debugging techniques and delta debugging as part of “testing literacy.”

Debate: is testing more important than DSA?

• Many argue the article is misread: it doesn’t say “testing instead of DSA”, but “less time on deep DSA implementation, more on testing practice,” especially since libraries exist.
• Several insist fundamentals like data structures, algorithms, and computer architecture are hard, non-absorbed-on-the-job skills that pay off long-term; by contrast, they claim testing “comes naturally” and isn’t fundamental.
• Others strongly disagree, saying poor testing and untestable designs cause more real project failures than lack of exotic data structures. Testing skill is framed as enabling safe refactoring and de‑risking complexity.

DSA in practice: when it matters

• Consensus that most developers rarely implement complex structures, but must understand their performance traits and when to use them.
• Multiple people defend “niche” structures like Bloom filters and sketches as essential in large-scale or distributed systems; others say they’ve never needed them.
• Several note that most performance work is about avoiding accidental O(n²) and leveraging caches/arrays, not inventing new algorithms.

Curriculum, interviews, and realism

• Many see university curricula overweighting hand-rolled data structures and underweighting testing, profiling, and practical engineering.
• There’s criticism of interview processes that treat DSA questions as universal signal, ignoring that most work is CRUD, data plumbing, or infrastructure already built on robust libraries.
• Some propose DSA as a “proxy” for problem-solving ability but agree it’s overused.

Limits and challenges of testing

• Thread highlights that testing can’t prove correctness, especially for concurrency; tools and techniques exist, but robust concurrent testing is rare in many shops.
• Large-scale “bot army” or simulation tests are praised for surfacing subtle, long‑running bugs.
• Several warn that mediocre, brittle tests can impede change as much as they help.