Как выполнить модульное тестирование класса ввода консоли?

Вы можете использовать expect.

По сути, ваш класс должен иметь возможность использовать случайный входной поток, а не только стандартный ввод (и вам необходимо провести его рефакторинг, если он еще не может).

После этого вы сможете просто создать фиктивный поток с вашими пользовательскими данными и смоделировать любой пользовательский ввод.

Макет ввода.

Если ваша платформа – .NET, вот один из способов сделать это< /а>.

Я планирую использовать GNU readline для пользовательского ввода. На данный момент я не вижу способа перенаправить входной поток этой библиотеки.

Создайте абстрактный класс с членами, соответствующими функциональным возможностям readline, которые вы хотите использовать. Программируйте для этого абстрактного класса, а не непосредственно для readline API. Используйте внедрение зависимостей, чтобы передать экземпляр этого класса коду, который в нем нуждается.

Затем вы можете создать две реализации этого класса: одну, которая просто обертывает библиотеку readline, и другую фиктивную реализацию, которую вы можете использовать в своих модульных тестах. В фиктивной реализации будут дополнительные члены, которые упростят имитацию пользователя.

Для .NET/C# вы можете использовать класс Options или варианты, найденные в этом вопросе. Поскольку у вас есть все команды, сопоставленные с делегатами, вы можете затем протестировать каждый из методов в конце делегатов и легко найти неизвестные команды:

MyHandler handler = new MyHandler()
CommandOptions options = new CommandOptions();

// Put this in the test Setup
options.Add("show", handler.Show)
        .Add("connect", v => handler.Connect(v))
        .Add("dir", handler.Dir);

if (!options.Parse(args))
   Assert.Fail(string.Format("{0} was not recognised.",args))

Класс MyHandler будет похож на:

public class MyHandler
{
    public void Show() { }
    public void Connect(string[] args){}
    public void Dir() {}
}

Для консоли я всегда просто оборачиваю ее своей собственной реализацией.

Использование оболочки и интерфейса для всех сторонних элементов управления, которые участвуют в модульных тестах, делает работу с изоляционной структурой (например, Rhino Mocks) очень простой. Это дает мне контроль над тестированием и явно определяет зависимости в моем коде. Поскольку мне нужны новые функции консоли, я могу просто добавить их в интерфейс обертки. У меня еще не было проблем с раздуванием интерфейса...

public interface IConsoleShim
{
    void WriteLine(string message);
    ConsoleKeyInfo ReadKey();
}
public class ConsoleShim : IConsoleShim
{
    public void WriteLine(string message)
    {
        Console.WriteLine(message);
    }
    public ConsoleKeyInfo ReadKey()
    {
        return Console.ReadKey();
    }
}

Вот тест в действии

[NUnit.Framework.Test]
public void Run_writes_to_console_100_times_waits_for_keypress()
{
    // arrange
    Rhino.Mocks.MockRepository mocks = new Rhino.Mocks.MockRepository();
    IConsoleShim consoleMock = mocks.StrictMock<IConsoleShim>();
    Program program = new Program(consoleMock);
    int expected = 100;

    // VerifyAll automatically called
    Rhino.Mocks.With.Mocks(mocks).Expecting(() =>
        {
            Rhino.Mocks.Expect.Call(() => consoleMock.WriteLine("")).IgnoreArguments().Repeat.Times(expected);
            Rhino.Mocks.Expect.Call(consoleMock.ReadKey()).Return(new ConsoleKeyInfo());
        });

    //act
    program.Run();
}