Как я могу лучше всего записать случаи модульного теста для Синтаксического анализатора?

int[] opcodes = Parser.GetOpcodes("set lcl_var = 2");
Assert.AreEqual(2, opcodes.Length);
Assert.AreEqual(0x10000010, opcodes[0]);
Assert.AreEqual(0x01000002, opcodes[1]);

Это зависит от того, как Вы структурировали свой синтаксический анализатор. Модульный тест тестирует единый блок.

Так, если Вы хотите протестировать свой весь синтаксический анализатор как единый блок, можно дать ему список команд и проверить, что он производит корректные коды операций (который Вы проверили вручную, когда Вы записали тест). Можно записать тесты для каждой команды и протестировать нормальное использование, использование пограничного случая, just-beyond-edge-case использование. Например, протестируйте это:

набор lcl_var = 2

результаты в:

0x10000010 0x01000002

И то же для 0,-1, MAX_INT-1, MAX_INT+1...

Вы знаете корректный результат для этих значений. То же идет для различных переменных.

Если Ваш вопрос, "Как я запускаю тот же тест с различными исходными данными и математическими ожиданиями, не пишущий один тест xUnit на комбинацию ввода - вывода?"

Затем ответ на это должен был бы использовать что-то как расширение RowTest NUnit. Я записал, что быстрая начальная загрузка недавно размещает в моем блоге. Пример этого был бы

[TestFixture]
    public class TestExpression
    {
        [RowTest]
        [Row(" 2 + 3 ", "2 3 +")]
        [Row(" 2 + (30 + 50 ) ", "2 30 50 + +")]
        [Row("  ( (10+20) + 30 ) * 20-8/4 ", "10 20 + 30 + 20 * 8 4 / -")]
        [Row("0-12000-(16*4)-20", "0 12000 - 16 4 * - 20 -")]
        public void TestConvertInfixToPostfix(string sInfixExpr, string sExpectedPostfixExpr)
        {
            Expression converter = new Expression();
            List<object> postfixExpr = converter.ConvertInfixToPostfix(sInfixExpr);

            StringBuilder sb = new StringBuilder();
            foreach(object term in postfixExpr)
            {
                sb.AppendFormat("{0} ", term.ToString());
            }
            Assert.AreEqual(sExpectedPostfixExpr, sb.ToString().Trim());
        }

Вы не указываете, в каком языке Вы пишете синтаксический анализатор, таким образом, я собираюсь принять ради аргумента, что Вы используете объектно-ориентированный язык.

Если это верно, затем внедрение зависимости могло помочь Вам здесь. Если место назначения испускаемых кодов операций является экземпляром класса (как Файл, например), попытайтесь дать Вашему эмиттерному классу конструктора, который берет объект того типа использовать в качестве места назначения для испускаемого кода. Затем от модульного теста можно передать в фиктивном объекте, это - экземпляр подкласса целевого класса, получите испускаемые коды операций для определенных операторов и утверждайте, что они корректны.

Если Ваш целевой класс не легко расширяем, можно хотеть создать интерфейс на основе его, что и целевой класс и ложный класс могут реализовать.

Насколько я понимаю Вы сначала записали бы тест для своего определенного примера, т.е. где вход к Вашему синтаксическому анализатору:

set lcl_var = 2

и вывод:

0x10000010 // load immdshort 2
0x01000002 // strlocal lclvar 

Когда Вы реализовали производственный код, чтобы пройти тот тест и осуществили рефакторинг его, затем если Вы не satisified, он мог бы обработать любую локальную переменную, записать другой тест с другой локальной переменной и видеть, передает ли он или нет. например, новый тест с входом:

set lcl_var2 = 2

И запишите свой новый тест для ожидания другого вывода, который Вы хотите. Продолжайте делать это, пока Вы не удовлетворены, что Ваш производственный код достаточно устойчив.

Не ясно, ищете ли Вы методологию или определенную технологию для использования для тестирования.

Насколько методология идет, возможно, Вы не хотите делать обширное поблочное тестирование. Возможно, лучший подход должен был бы записать некоторые программы в Вашем предметно-ориентированном языке и затем выполнить коды операций для приведения к результату. Тестовые программы затем проверили бы этот результат. Таким образом, можно осуществить набор кода, но проверить только один результат в конце. Начните с простых спугивать очевидные ошибки и перемещение к более твердым. Вместо того, чтобы проверить сгенерированные коды операций каждый раз.

Другой подход для взятия должен автоматически генерировать программы в предметно-ориентированном языке наряду с ожидаемыми кодами операций. Это может быть очень просто как запись сценария жемчуга, который производит ряд программ как:

набор lcl_var = 2

набор lcl_var = 3

После того как у Вас есть комплект тестовых программ на Вашем языке, которые имеют корректный вывод, можно пойти назад и генерировать модульные тесты, которые проверяют каждый код операции. Так как у Вас уже есть коды операций, это становится вопросом осмотра вывода синтаксического анализатора для правильности; рассмотрение его кода.

В то время как я не использовал cppunit, я использовал внутренний инструмент, который очень был похож на cppunit. Было легко реализовать модульные тесты с помощью cppunit.

Что Вы хотите протестировать? Вы хотите знать, создается ли корректная инструкция "по хранилищу"? Взята ли правильная переменная? Решитесь, что Вы хотите знать, и тест будет очевиден. Пока Вы не знаете то, чего Вы хотите достигнуть, Вы не будете знать, как протестировать неизвестное.

Тем временем просто запишите простой тест. Завтра или некоторый более поздний день, Вы приедете в это место снова, потому что что-то повредилось. В то время Вы будете знать больше о том, что Вы хотите сделать, и могло бы быть более просто разработать тест.

Сегодня, не пытайтесь быть человеком, которым Вы будете завтра.