2014-02-10 2 views
1

Как отделить это?Позволяет ли Visual Studio выборочно запускать тестовые примеры?

Скажем, есть модуль, построенный с контрактом (т. Е. Реализующий интерфейс). Это делается для единичных целей тестирования и расширяемости.

Скажите, что в моей команде есть человек (A), умеющий писать блок-тесты для модуля доступа к данным. Поэтому его код просто создает этот интерфейс после загрузки соответствующих интерфейсов и сборок. И этот человек записывает тестовые примеры с использованием интерфейса в качестве основного объекта теста. (Не уверен, что это правильное использование слов).

Другой человек (B), являющийся фактическим разработчиком модуля, и который немного новичок в написании кода (и не обладает огромным знанием инфраструктуры .net). Даже он также пишет некоторые тестовые примеры. Он/она пишет код для модуля в соответствии с инструкциями по спецификации, указанными руководителем команды (как упоминалось выше).

Так что тестовые примеры A были бы более похожими на системные цели. Но тестовые примеры B больше похожи на изучение инфраструктуры .net. Напр. это может быть что-то вроде изучения File.Replace. Если вы не прочтете документы об этом очень хорошо, вы, вероятно, подумаете, что два файла, «где угодно» в файловой системе, могут быть «заменены». Однако документы говорят иначе. Но скажите, B, не знает об этом. Он пишет тестовые примеры, чтобы узнать об этом.

Итак, обобщая все это, есть две группы единичных тестовых случаев. Чтобы иметь возможность отслеживать усилия и производительность и, возможно, выходить с планом обучения для B, мне понадобятся оба тестовых примера. Однако, проверяя модуль доступа к данным в целом, мне нужно было только выполнить тестовые примеры A.

Позволяет ли Visual Studio сделать это? Выборочно запускать тестовые примеры. Как я могу быстро запустить все тестовые примеры A?

ответ

3

Это зависит от того, какую тестовую библиотеку вы используете. Если вы используете MsTest, вы можете использовать TestCategories.

[TestCategory("Nightly"), TestCategory("Weekly"), TestCategory("ShoppingCart"), TestMethod()] 
public Void DebitTest() 
{ 
} 

Аналогично, если вы используете NUnit вы можете использовать Categories.

namespace NUnit.Tests 
{ 
    using System; 
    using NUnit.Framework; 

    [TestFixture] 
    [Category("LongRunning")] 
    public class LongRunningTests 
    { 
    // ... 
    } 
} 

UPDATE

Если вы действительно должны запустить их в визуальной студии, я бы рекомендовал using playlists вместо этого, однако я бы вопрос в пользу этого. При этом необходимо вручную проверять тестовые примеры или охват, поскольку ошибки могут быть сделаны. Вы должны автоматизировать это как часть процесса сборки. Я часто думаю, что визуальная студия делает вещи, которые он не рекомендовал бы (например, это), было трудно сделать.

Я также предложил бы, чтобы вы получили человека A и человека B для совместной работы программы. Навыки менее опытного человека будут улучшаться быстрее, поскольку человек A передает знания человеку B и качество должно быть выше, чтобы вы могли двигаться быстрее.

+0

Вы должны запустить это из командной строки? Не существует ли способ сделать это? Я имею в виду, когда вы используете тестовую инфраструктуру Ms, встроенную в VS? – deostroll

+0

@deostroll обновил мой ответ. –

0

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

Это, как правило, вопрос how high of quality your tests should be. И, оставив одну часть кодовой базы низкого качества, обычно не очень хорошая идея. Даже если вы попытаетесь четко обозначить это.

+0

Младший тестовый код разработчика не является частью кодовой базы как таковой. Это также форма документации, почему он или она решил написать этот код. Эти тестовые подпрограммы не будут пересматриваться, но материалы, написанные в модуле, будут рассмотрены. – deostroll

Смежные вопросы