> The "doesn't include non-active projects objections is easy", please check the Example 1 test again, there's a line for that:
You're correct; I totally missed that.
> In either case it is up to you to make sure that the projects are representative.
That's fair, but that's also the point you're trying to address / make more robust by how you're trying to write tests (what the article is about). Specifically
- The article is about: How to make sure you're tests are robust against test fixtures changing
- That comment says: It's up to you to make sure your test fixtures don't change in a way that breaks your tests
> You can write a test that is equally powerful as if you restricted your fixtures just to those example projects and then made an absolute comparison. You're not loosing any testing power. Expect you're making the test easier to maintain.
By restricting your fixtures to just the projects (that are relevant to the test), you're making _the tests_ easier to maintain; not just the one test but the test harness as a whole. What I mean is that you're reducing "action at a distance". When you modify the data for your test, you don't need to worry about what other tests, somewhere else, might also be impacted.
Plus you do gain testing power, because you can test more things. For example, you can confirm it returns _every_ active project.
All that being said, what I'm talking about relies on creating the test data local to the tests. And doing that has a cost (time, generally). So there's a tradeoff there.