Unit-testing – Is it considered ‘bad practice’ to check file contents/encoding in unit tests

once I pick an algorithm I may never use the others,

False for well-written tests which exercise the interface of the algorithm.

If your tests exercise implementation details, and the implementation no longer applies, then the tests no longer apply. Delete them.

and once a test shows why another test is failing, I can correct the initial test (or its exercised production code) and verify correctness, and I no longer care that the other test's hard-coded exercise environment still fails.

Um. You should fix the "other test's hard-coded exercise environment" so that it's meaningful and useful and correct.

If a test is wrong (even if redundant) it should be corrected so that it's right.

TDD means tests are right, first and foremost. Code will get right eventually.

"and it fails, so I'll just ignore it"

This is not a potential for abuse. This is abuse.

You cannot ignore a failing test. If the test is wrong it must be fixed.

Removing tests that seem redundant is a waste of time. Extra testing never hurt anybody. Indeed, it may uncover super-subtle errors that pass one version of a test by fail another version of a superficially similar test. This may indicate design errors in an interface more than an implementation bug.

What you're doing is integration testing, because as you can probably tell, your tests have dependencies on other parts of your code. This is fine, but it's good to know when you're looking at articles/examples/etc. online.

Some points to consider, and things to remember:

• Arrange, Act, Assert. All tests have these 3 steps.
  • Need more steps? You're probably testing too much for 1 test
  • No Arrange? You have external dependencies, which almost always makes tests flaky and unreliable.
  • Lots of Arrange code usually means lots of dependencies, and system-state types of dependencies. That's a recipe for fragile code.
  • No Act? Often tests the compiler. Leave that to compiler developers.
  • Lots of Act(s)? You're probably testing too much for 1 test again.
  • No Assert? Often the case when you want to test that "no errors occurred". No errors != working correctly.
  • Lots of Asserts? The code under test might be doing too much/touching too many systems. Try refactoring and testing the individual bits instead.
• Tests should exist on their own. Avoid scenarios where something that tests 3 depends on the code that does 1. Instead, look to replace the code that does 1 with test code. In your scenario: try manually setting the values to what you want them to be in the test's Arrange step, then perform the Act ion (the calculations), then Assert the result.
• Happy-path tests are often a waste of time. Best-case scenarios almost always work. Your tests should be trying to force errors and edge cases.
  • Do you have a test that passes bad streams to be processed?
  • Do you have a test that passes null/non-existant filenames to be processed?
  • What happens if the numeric values to compute are not numeric, or when parsed are huge, or produce huge values when computed?
• Surprisingly writing tests rarely confirms that what you've done is right. Instead they give you insight into how usable, stable, and flexible your design is.

edit> This has already been accepted, but I wanted to add something that I learned long ago via Pragmatic Unit Testing:

Unit Testing with your Right BICEP

• Are the results Right ?
• CORRECT B oundary Conditions
  • C onform to expected format
  • O rdered correctly
  • R ange is correct
  • R eferences to external dependencies are safe
  • E xistence (null etc.)
  • C ardinality
  • T iming (things happen in the right order, with the correct timing)
• I nverse relationships
• C ross-Check results with other means
• E rrors are forced
• P erformance characteristics are within acceptable bounds