Writing Tests for methods not exposed to UI - general help needed

Question

I'm totally new to TDD and am using NUnit to write tests for a Card Game application in writing in C#.

Mostly its proving really useful, but there are some things I'd like to test, but don't wish to expose any public properties from which to do so.

For example, I'd like to be able to test that a new card deck consists of 4 suits, each with 13 cards. it might look something like:

[Test()]
public void ADeckOfCardsHas4Suits()
{
   Game game = new Game();
   Assert.AreEqual(4, game.Deck.SuitCount);
   Assert.AreEqual(13, game.Deck.GetCards(Suit.Spades).Count)
}

With SuitCount returning something like:

return this.cards.Select(c => c.Suit).Distinct().Count();

And GetCards(Suit suit):

return this.cards.where(c => c.Suit == suit);

However I don't want to expose these properties or methods in the API to the UI (I may not even wish to expose Deck), but am not sure how I can test against them without making them public.

Are there any generally accepted ways of doing this?

Cheers

Stewart

Answer 1

In this scenario we often use (abuse?) friend assemblies to allow the test project to see the internal members of the class under test.

Edit:

In your main project add a FriendAssemblies.cs file:

using System.Runtime.CompilerServices;

// making internals available to the testing project
[assembly: InternalsVisibleTo( "MyProject.IntegrationTests" )]
[assembly: InternalsVisibleTo( "MyProject.UnitTests" )]

Answer 2

Certainly clients of your card deck should be able to access and iterate through the cards in a given desk, shouldn't they? I.e. the deck should publish something like an IEnumerable<Card>.

If so, your unit tests can grab this and use it to count the number of distinct suits. The methods SuitCount and GetCardsOfSuit should thus be implemented as helpers in your unit test code.

Answer 3

You should test the public behaviour of your class. If the UI talks to a Game and needs to know how many suits there are then rather than game.Deck.SuitCount test game.GetDeckSuitCount() if you have more than 1 Deck overload the method to specify which Deck via a parameter game.GetDeckSuitCount(2). This way Deck is hidden from Game's clients and is encapsulated.

Also consider that you might need to test Deck and the services it provides to Game independently, in which case it would be preferable to supply it as a dependency to Game explicitly via Game's constructor.

This approach also allows you to depend on an interface rather than an implementation which facilitates supplying a different implementation of Deck to Game either for mocking or to allow you the flexibility to supply an alternative implementation of Deck to Game in future.

e.g.

public interface IDeck{
    // provide the methods and properties that Game requires from Deck
}

public class PokerDeck:IDeck{
    // ... etc
}

public class TravelCardsDeck:IDeck{
    // ... etc
}

// [Test]
IDeck deck = new TravelCardsDeck();
var game = new Game(deck);
Assert.That(game.GetDeckSuitCount(),Is.EqualTo(4));

Answer 4

In this case, I wouldn't immediately care about the content. If you model the act, you are given a set of cards that become a deck (below, a Deck takes an IEnumerable<Card>). Then you would shuffle them and deal them out.

public class Deck
{
    ...
    public Deck(IEnumerable<Card> cards) { ... Shuffle() ... }        
    public void DealTo(IDealable dealable, int numberOfCards) {...}
}

Here you create a simple test case that deals out one card:

var deck = new Deck(new Card[] { <somecard> });
var hand = new Hand(); 

deck.DealTo(hand, 1);

Assert.AreEqual(<somecard>, hand[0]);

... plus whatever tests you can think up.

Then you create a poker deck:

public class PokerDeck : Deck
{
    public PokerDeck() : base(<poker cards>)
}

// Pinochle, Uno, whatever 

So to test the PokerDeck, you would probably start with something like this:

var deck = new PokerDeck();
IDealable testHand = new TestDealable();
deck.DealTo(testHand, 52);

//assert all are distinct
//assert all make up expected deck
//assert is shuffled

// test with multiple players / "dealables"

Simulating Texas Hold'em would be something like this:

// first card
foreach(var player in players)
   deck.DealTo(player, 1);

// second
foreach(var player in players)
   deck.DealTo(player, 1);

// wait for action

// flop
deck.DealTo(burnPile, 1);
deck.DealTo(board, 3);

// wait for action

// turn
deck.DealTo(burnPile, 1);
deck.DealTo(board, 1);

// wait for action

// river
deck.DealTo(burnPile, 1);
deck.DealTo(board, 1);

Answer 5

As suggested, I'd use the InternalsVisibleTo attribut to allow a test assembly to exercise the production assembly's code.

I would, however, extract the internal behaviors and implementations into separate, internal classes.

This way, I can test the public API classes, without relying on any internal behavior, and if the internal behaviors change, only the behaviors' tests will be affected; if you don't do that, you will find yourself with brittle tests, and public API tests that may break due to internal implementation changes.