Примеры практики, Тестирующие код C#
Как уже упоминалось в комментариях read и accept, операции обычно блокируются на Socket.
Вы можете создать собственный Thread, который ожидает сообщения от вашего Socket, а затем изменить графический интерфейс. Имейте в виду, что Swing не безопасен для потоков.
Если мне нужно создать собственный Thread, я использую интерфейс Runnable. Вы можете достичь этого следующим образом:
public class MySocketListener implements Runnable {
private final GUIClass guiClass;
private final ServerSocket serverSocket;
private Socket clientSocket;
public MySocketListener(GUIClass guiClass, ServerSocket serverSocket) {
this.guiClass = guiClass;
this.serverSocket = serverSocket;
}
/* Everything that happens in this method, is done on another Thread. */
@Override
public void run() {
try{
this.clientSocket = this.serverSocket.accept();
Scanner sc = new Scanner(this.clientSocket.getInputStream());
while(true) {
/* Blocking operations */
this.guiClass.doSomething();
}
} catch(IOException ex) {
ex.printStackTrace();
}
}
}
Затем можно легко запустить Thread:
Thread socketListenerThread = new Thread(new MySocketListener(this, serverSocket));
socketListenerThread.start();
Для получения дополнительной информации ознакомьтесь с темой и документация на сокет .
13 ответов
Вот пример. Следует иметь в виду, что Ваш пример кода испытал недостаток в определениях многих зависимостей:
[TestFixture()]
public class TestHole
{
private Hole _unitUnderTest;
[SetUp()]
public void SetUp()
{
_unitUnderTest = new Hole();
}
[TearDown()]
public void TearDown()
{
_unitUnderTest = null;
}
[Test]
public void TestConstructorHole()
{
Hole testHole = new Hole();
Assert.IsNotNull(testHole, "Constructor of type, Hole failed to create instance.");
}
[Test]
public void TestNotifyPropertyChanged()
{
string info = null;
_unitUnderTest.NotifyPropertyChanged(info);
}
}
Вы видите, что это тестирует это, конструктор производит доступный объект (обычно не необходимый с полным тестовым приспособлением на месте, конструкция обычно хорошо осуществляется), и это также тестирует единственный открытый метод в классе. В этом случае Вам были бы нужны делегат обработчиков событий и Утверждение для проверки информационного содержания параметра.
Цель к тестам записи, которые осуществляют каждый метод Вашего класса. Обычно это включает верхние и нижние границы, а также состояние отказа.
Вы не можете правильно протестировать этот код, если спецификация также не дана. "Тестирование" обычно означает удостоверяться работы программного обеспечения, как разработано.
Править: Это - действительно не "полицейский" ответ. Я работал тестером прежде, и я могу сказать Вам, что почти все тестовые сценарии, которые я записал, были получены прямо из спецификации программного обеспечения.
Пример модульного теста:
- Проверьте, что Событие PropertyChanged запущено с корректным событием args. Используйте отражение в тесте для итерации всех свойств, устанавливающих значения и проверяющих на событие.
Обычно это сделано со средой тестирования, такой как NUnit.
(Вид забавной причины, Вы заметите, что свойство ParentPattern не запускает событие.)
Я скажу Вам большую тайну о тестировании.
Когда Вы пишете тест, Вы пишете программное обеспечение, которое проверяет другое программное обеспечение. Это проверяет, что Ваши предположения верны. Ваши предположения являются просто операторами. Вот является немой простой тест тем дополнением работы.
if( 1 + 1 == 2 ) {
print "ok - 1 plus 1 equals 2\n";
}
else {
print "not ok\n";
}
Те операторы, те утверждения, должны быть верными или иначе существует ошибка, или функция отсутствует. Это определяет ошибки быстрее, прежде чем они станут волосатыми, систематическими ошибками, прежде чем пользователь будет видеть их. Места ошибки к проблеме, которая должна быть решена. Идеально, это также дает Вам достаточно информации для диагностирования проблемы. Сфокусированный тест и диагностика делают отладку намного быстрее.
Вы пишете это программное обеспечение, чтобы сделать Вашу работу для Вас. Чтобы сделать это лучше, чем Вы может. Вы могли протестировать программное обеспечение вручную, визуальный контроль вывод, но тесты, однажды записанные, не уходят. Они создают и создают и создают, пока нет большая масса того, что они тестировали на новые возможности, старые функции, новые ошибки и старые ошибки. Задача тестирования Вашего нового кода вручную, а также проверки, Вы не повторно ввели некоторую старую ошибку, быстро становится подавляющей. Человеческая воля просто прекращает тестировать на старые ошибки. Они будут повторно введены, и время будет потрачено впустую. Тестовая программа может сделать все это для Вас при нажатии кнопки. Это - скучная, механическая задача. Люди сосут в них, это - то, почему мы изобрели компьютеры. Путем записи программного обеспечения для тестирования программного обеспечения Вы используете компьютер для того, что это было предназначено: экономить время.
Я поместил его в такие упрощенные условия, потому что люди, которые плохо знакомы с тестированием, часто поражаются. Они думают, что существует некоторое волшебство. Некоторая специальная платформа они должны использовать. Они часто даже забывают, что тесты являются все еще программами и внезапно не могут думать, чтобы использовать цикл или записать подпрограмму. Существует очень, намного больше для изучения, но надо надеяться это даст Вам ядро, вокруг которого можно выяснить, какова эта "тестовая" вещь.
Тестирование не является просто разработкой - это - искусство. Что-то, что требует, чтобы Вы читали. Я не так уверен, что для нас будет возможно преподавать Вам через этот единственный вопрос все Вы, want/need/ought/should/must знают. Для начинаний вот, несколько вещей, которые можно протестировать.
- Единица (соединяет интерфейсом с работой как ожидалось),
- Интеграция (компоненты ведут себя между собой),
- Удобство использования (клиенты удовлетворены),
- Функциональный (завершенная функция)
Определите ряд критериев против каждого (метрики) и начните тестировать.
Отчасти в стороне, кажется, что большая часть этого класса не должна должна быть быть протестирована (кроме ответа Gord), если бы класс был записан другим способом. Например, Вы смешиваете информацию модели (holetype, и т.д.) с информацией о представлении (толщина). Кроме того, я думаю, что Вы упускаете суть WPF и привязку данных/триггеры. UpdateHoleType () Должен быть выражен в .xaml файле как ряд DataTriggers и того же с UpdateEntities (), и большинство других свойств, которые Вы имеете.
В поблочном тестировании Вы просто тестируете свои "видимые" методы/свойства а не частные.
Так, например, в Вашем коде можно добавить следующий тест:
hole.Visible = false;
Debug.Assert( "".Equals( hole.AbsXDisplay ) );
Debug.Assert( "".Equals( hole.AbsYDisplay ) );
Вы могли бы думать "хорошо, что это очевидно!" но после нескольких недель, Вы могли бы забыть об этом. И если некоторая часть Вашего кода зависит от значения AbsXDisplay (который является общедоступным атрибутом), и по некоторым причинам после установки свойства на ложь это больше не, "" но "пусто" или "NotSet" затем, этот тест перестанет работать, и Вы будете сразу уведомлены.
Вы, как предполагается, делаете это для каждого открытого метода или атрибута, которые имеют некоторое бизнес-правило в нем или то влияние некоторая другая часть Вашего класса.
Некоторые люди находят легче протестировать сначала (и сделать тестовый сбой) и затем кодировать для удовлетворения теста, тот способ, которым Вы кодируете только, что Вы тестируете, и Вы тестируете только, о чем Вы заботитесь (поиск TDD)
Это было только простым примером того, что можно сделать для тестирования кода.
Я надеюсь, что это помогает Вам дать Вам хорошую идею того, о чем тест - все.
Как другой предложили, ищите среду тестирования.
Путем тестирования я предполагаю, что Вы имеете в виду тест управляемый дизайн. Протестируйте управляемый дизайн, главным образом интересуется модульными тестами и иногда интеграционными тестами. Модульные тесты тестируют наименьший код, тестируемые элементы кода и тесты интеграции тестируют взаимодействие между компонентами с Вашим приложением.
Существует намного больше форм тестирования, но они - те, разработчики обычно делают самостоятельно. Другие тесты главным образом смотрят на приложение извне и интерфейсы проверочного пользователя, выставленные по различным качествам как правильность, производительность и масштабируемость.
Поблочное тестирование включает тестирование Ваших методов, чтобы видеть, делают ли они то, к чему Вы хотите их. Это обычно тест, настолько простой, Вы почти думали бы их тривиальный. Вещью, которую Вы надеетесь тестировать, является логика Вашего класса. Класс Вы обеспечивает, действительно не имеет всей так большой логики.
Только private void UpdateHoleType(){...} содержит любую логику, которую это, кажется, визуально ориентировано на логику, всегда самое твердое для тестирования. Запись тесты очень проста. Ниже пример для развернутого holetype.
[Test]
public void testDrilledHole()
{
Hole hole = new Hole();
hole.HoleType = HoleTypes.Drilled;
Assert.AreEqual(Visibility.Collapsed, hole.HoleDecorator.Visibility);
}
При рассмотрении его Вы почти не считали бы это стоящим того. Тест тривиален и очевиден. [Test] атрибут объявляет метод тест и Assert.AreEquals() метод выдает исключение, если обеспеченные значения не равны. Фактическая конструкция может варьироваться в зависимости от используемой среды тестирования, но они все одинаково просты.
Прием здесь - Вы, пишут эти методы для всех методов в Вашей бизнес-логике выполнения класса и тестируют много значений. null всегда хорошее значение для попытки.
Питание поблочного тестирования находится в комбинации всех тех тестов. Теперь при изменении чего-то в классе существует много тестов, проверяющих, если изменение, которое Вы внесли, повреждения одно из поведений, которые Вы определили в своем тесте. Это позволяет Вам работать с большим проектом, изменением и реализованием новых опций, в то время как тесты сохраняют функциональность, Вы уже кодировали.
Тесты помогут, если необходимо внести изменения.
Согласно Растушевкам (Растушевки, Работая Эффективно с Унаследованным кодом, p. 3) существует четыре причины изменений:
- Добавление опции
- Исправление ошибки
- Улучшение дизайна
- Оптимизация использования ресурсов
Когда существует потребность в изменении, Вы хотите быть уверенными, что Вы ничего не повреждаете. Быть более точным: Вы не хотите повреждать любое поведение (Поиск, Thomas, Прагматическое Поблочное тестирование в C# с NUnit, p. 31).
С поблочным тестированием на месте можно сделать изменения с намного большей уверенностью, потому что они были бы (если они программируются правильно), изменения получения в поведении. Это - преимущество модульных тестов.
Было бы трудно сделать модульные тесты на класс, который Вы дали как пример, потому что модульные тесты также требуют определенной структуры кода под тестом. Основания, которые я вижу, состоят в том, что класс делает слишком много. Любые модульные тесты, которые Вы примените на тот класс, будут довольно хрупкими. Незначительное изменение может составить Ваш удар модульных тестов, и Вы закончите тем, что тратили впустую много времени с решением проблем в Вашем тестовом коде вместо Вашего производственного кода.
Получать выгоду модульных тестов требует для изменения производственного кода. Просто применение принципов модульных тестов, не рассматривая это не даст Вам положительный опыт поблочного тестирования.
Как получить положительный опыт поблочного тестирования? Будьте непредубежденными для него и учитесь.
Я рекомендовал бы Вам Работающий Эффективно с Унаследованным кодом для существующего основания кода (как та часть кода, который Вы дали выше). Поскольку легкий удар запускается в Прагматическое Поблочное тестирование попытки поблочного тестирования в C# с NUnit. Реальное сенсационное сообщение для меня было Тестовыми Шаблонами xUnit: Рефакторинг Тестового кода.
Удача в Вас поездка!
один пример,
для
общедоступный HoleTypes HoleType
протестируйте / проверка на пустой указатель в наборе
Мы должны протестировать его, правильно?
Тесты являются проверкой, что код работает, поскольку Вы ожидаете, что это будет работать. Запись тестов для этого класса прямо сейчас не приведет к Вам никакая реальная выгода (если Вы не раскроете ошибку при записи тестов). Реальная выгода - когда необходимо будет возвратиться и изменить этот класс. Можно использовать этот класс в нескольких различных местах в приложении. Без тестов изменения в классе могут иметь непредвиденные последствия. С тестами можно изменить класс и быть уверены, что Вы не повреждаете что-то еще, если все Ваши тесты передают. Конечно, тесты должны быть правильно написаны и покрыть всю функциональность класса.
Так, как протестировать его?
На уровне класса необходимо будет записать модульные тесты. Существует несколько платформ поблочного тестирования. Я предпочитаю NUnit.
На что я тестирую?
Вы тестируете это, все ведет себя, поскольку Вы ожидаете, что это будет вести себя. Если Вы дадите метод X, то Вы ожидаете, что Y будет возвращен. В ответе Gord он предложил тестировать то Ваше событие, на самом деле исчерпывает. Это было бы хорошим тестом.
Книга, Гибкие Принципы, Шаблоны и Методы в C# Дядей Bob действительно помогли мне понять, какой и как протестировать.
С точки зрения события Notify, увольняющего Вас, должен, конечно, удостовериться, работает ли Ваш класс согласно спецификации, а именно, что:
- Parent никогда не будет стрелять независимо от набора значений
- StrokeColour и StrokeThickness всегда запускают событие, даже при том, что то же значение установлено
- CanvasX/Y, HoleType/Dia только стреляют, когда значение, отличающееся, чем предыдущее, установлено
Затем Вы хотите проверить несколько побочных эффектов, которые вызывает установка Ваших свойств. После этого Вы могли думать о рефакторинге вещи, потому что, блин, это не симпатичный класс!
Ну, история начинается с теории.
Это - то, что я сделал.
Во-первых, если Вы программируете на языке OO, изучают шаблоны разработки. Является самым легким, если Вы формируете исследовательскую группу и учитесь вместе с некоторыми друзьями и коллегами.
Проведите несколько месяцев к легкому обзору все шаблоны.
Затем переместитесь в рефакторинг методов, где Вы изучите, как преобразовать любой код для кодирования, который будет использовать ранее изученные блоки, например, шаблоны разработки.
После этой подготовки тестирование будет так же легко как любой другой метод программирования.