The confusion you are having here is because you are trying to write a test about the implementation details, not about the desired effect. Thinking instead about the desired behaviors of the class is likely to lead you to a better test.

In this example, it seems to me you have two behaviors you want to test:

• When added an effect does something to the character
• When it is removed the effect reverts the change to the character

I’m not exactly sure what a character effect is, but here’s an example test that makes a fairly reasonable assumption, and hopefully gets my point across even if it’s a little off:

[Test]
public void AddAndRemovingEffectsAltersCharachterAppropriately()
{
    var originalStrength = _character.Strength;
    CharacterEffect strengthPotion = new StrengthPotion();
    _character.Add(strengthPotion);
    Assert.That(_character.Strength, Is.GreaterThan(originalStrength));

    //normally I'd make a second test for this, 
    //but the answer edit box is not a great IDE  :)
    _character.Remove(strengthPotion);
    Assert.That(_character.Strength, Is.EqualTo(originalStrength));
}

Notice: this test doesn’t care about the collection at all. It’s not obvious from reading it that a collection is necessary. The collection is merely an implementation detail. It’s beneath the notice of the test.

Side note: The “add” and “remove” names for methods do suggest a collection, and don’t really communicate that domain relevant purpose of the methods. I’d prefer something like Apply or Consume over Add. Or perhaps character.Inventory.Add() if we are talking about equipment.

You seem to understand the incremental part of TDD, that is to implement the smallest possible functionality at a time. However, there are cases like the one you are facing that make it extremely difficult to do. In your particular situation, I would not bother trying to implement them separatly and I would implement Add and Contains at the same time.

The typical TDD cycle starts with : Write your test and make it compile. In your case, your test would look like so :

var g = new GameCharacter();
var c = new CharacterEffect();
g.Add(c);
Assert.That(g.Contains(c));

In order to make your test compile (step 2), you have to implement both Add and Contains, which I think is perfectly fine. TDD says that you should take the smallest step possible, and this seems to be the smallest you can do. You don’t need to go crazy about implementing every method individually or you will likely hit the same walls again and again.

It’s easy to test if the effect was applied to the character, but how do I test that the effect was added to _collection?

You shouldn’t.

You need to ask why it matters that an item is added to the collection. “Well, it should then have a certain effect on the character.” Then test for that effect. There isn’t any value in testing that a rudimentary collection works as a collection.

And suppose someday you modify the program to create character effects in a very different way. If you test that your collection works, your test becomes useless when you get rid of the collection. But if you test for character effects, your test will still work with a different code mechanism. That’s as it should be; you need to test that your program works correctly, not that your programming language works correctly.

Have a look at this answer, by Kent Beck, about what one should test:

How deep are your unit tests?

I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence…If I don’t typically make a kind of mistake (like setting the wrong variables in a constructor), I don’t test for it.

Unless you’re completely unfamiliar with the programming language you’re using or with a library you’re using, it just doesn’t make sense to test that a collection works as a collection, or that you can create a new object, or that a variable is incremented when you tell it to increment.

All you’re doing in such cases is making sure your programming language works as it’s designed to, which is generally not a thing you’d have to test unless you’re the one designing the language.

You shouldn’t test classes but interfaces where by interface, beside the typical meaning, you could also understand the signatures of the public methods of a class. Your classes should adhere to strong contracts; from the testing point of view (and from other clients’ POV) you shouldn’t care how those contracts are respected/implemented.

In your particular case there is a problem with your class design; your add method does two things: firstly it changes the CharacterEffect and then it adds that object to the collection of character effects. This bad design decision makes it difficult to test!

If you really want to see a private field, you can use reflection, but that is not an orthodox way of doing things.

Have your unit tests be implemented in a friend class.

That lets you poke into private and protected stuff freely for the purposes of the unit test without having to make it part of the external API.