Наследование поблочного тестирования
Документация для csvread является точной, но запутанной и несколько нестандартной для matlab. Основной синтаксис:
a = csvread(filename)
И если вы хотите указать диапазон, вы можете использовать:
a = csvread(filename,R1,C1,[R1 C1 R2 C2])
где R и C - интересующие строки и столбцы. Хитрость заключается в том, что значения строки и столбца имеют нулевой индекс , что необычно для matlab. Также обратите внимание, что если вы указываете диапазон для чтения, первые компоненты аргумента массива совпадают с остальными аргументами.
Например, рассмотрим файл «test.csv», который выглядит следующим образом:
1,2,3,4
1,2,3,4
1,2,3,4
1,2,3,4
Основная операция чтения:
>> a = csvread('testcsv.csv')
a =
1 2 3 4
1 2 3 4
1 2 3 4
1 2 3 4
Если вы хотите начать чтение с колонки 2, укажите строку 0 и столбец 1 :
>> a = csvread('testcsv.csv',0,1)
a =
2 3 4
2 3 4
2 3 4
2 3 4
И если вы хотите остановиться после столбца 3 при включении всех строк (то есть до строки 4) :
>> a = csvread('testcsv.csv',0,1,[0 1 3 2])
a =
2 3
2 3
2 3
2 3
В вашем конкретном случае:
>> a = csvread('testcsv2.csv')
a =
1 2 3 4 5
6 7 8 9 10
11 12 13 14 15
>> a = csvread('testcsv2.csv',1,1,[1 1 2 3])
a =
7 8 9
12 13 14
5 ответов
Если Вы используете современную платформу поблочного тестирования, я не понимаю оператор
Я не хочу тестировать все дочерние классы на это поведение.
Ваши модульные тесты (записанный против экземпляра родительского класса) должны работать неизменные, если Вы вручаете им экземпляр дочернего класса, при условии, что Ваш дочерний класс не переопределил некоторый аспект поведения родителя способом, которое нарушает условия контракта на унаследованных методах. И это точно, что необходимо тестировать, не так ли?
Если бы Вы обеспокоены временем, это берет для запущения тестов, я перепроверил бы, чтобы удостовериться, что тесты делятся таким образом, что можно выборочно запустить тесты на основе того, что Вы активно продолжаете работать (но все еще выполните полный портфель периодически для ловли непреднамеренных зависимостей.)
Вы не хотели бы тестировать тип объекта, если он не выходит из невведенного метода фабрики. Иначе Вы пишете модульный тест против компилятора C#, который не является тем, что Вы хотите сделать.
Я думаю, что запись теста, что наследование работает, является пустой тратой времени. Компилятор проверит, что методы базового класса доступны, при попытке использовать их, предполагая, что Вы не ловите с intellisense. Я, вероятно, протестировал бы поведение в одном дочернем классе и затем только в каждом дочернем классе, который изменяет поведение (или некоторое состояние, поведение зависит от).
Компилятор C# заботится о такой проверке на Вас.
Если Вам нравитесь Вы, может записать что-то как:
ParentClass childClass = new ChildClass()
var testOutput = childClass.ParentMethod();
Assert.IsNotNull(testOutput);
Существует два подхода, которые можно использовать для тестирования поведения базового класса:
- Создайте тупиковую реализацию базового класса и модульный тест тупик. Только протестируйте открытые методы. Бессмысленно протестировать Ваши закрытые и защищенные методы, так как они будут использованы открытыми методами, которые необходимо протестировать в подклассах. Этот подход не осуществит это, Ваши реализации базового класса не имеют затененного поведения неправильно.
- Создайте тестовый суперкласс для своих модульных тестов, который осуществляет методы базового класса. Каждый раз, когда Вы тестируете подкласс своего базового класса, имеете Ваш тестовый класс, наследовались Вашему тестовому суперклассу. Этот подход гарантирует, что Вы не изменили поведение базового класса непреднамеренно, но ограничивает гибкость Вашего теста.
Не потрудитесь проверять, что наследование на самом деле работает (целое Assert.IsTrue(new ChildClass() is ParentClass) вещь). Необходимо только протестировать поведение. Это - структурная функция платформы .NET (наследование), и необходимо положить, что это работает, иначе Вы окажетесь в нисходящей спирали проверки функций платформы.