Руководство по JUnit. Введение. Книга junit


Руководство по JUnit. Введение – PROSELYTE

Тестирование – это процесс проверки функционала программы с целью подтверждения того, что она работает в соответствии с определёнными требованиями. Unit-тестирование – это тестирование, которые пишутся, непосредственно, на уровне разработчика (тестирование определённой сущности – метод или класс). Это крайне важный этап разработки ПО, который помогает создавать качественный продукт.

Юнит-тестирование делится на две большие группы:

  • Ручное тестирование
  • Автоматизированное тестирование
Ручное тестирование Автоматизированное тестирование
Ручное выполнение тестов без помощи каких-либо средств. Использование специальных средств для автоматизированного тестирования
Не программируется

Нет возможности для написания сложных тестов для тестирования сложных моделей поведения.

Программируется

Тестировщики могут написать сложные тесты для тестирования сложных моделей программирования

Низкая надёжность

Ручное тестирование имеет низкую надёжность, так как крайне подвержено влиянию человеческого фактора.

Высокая надёжность

Автоматизированное тестирование точное и надёжное.

 

Большие затраты времени

Связано с тем, что человек имеет крайне ограниченные возможность в скорости работы.

Быстро

Автоматизированные тесты выполняются на порядок быстрее, чем это может сделать человек.

 

JUnit

JUnit – это фреймворк, разработанный для тестирования программ, написанных с использованием технологии Java. Он лежит в основе TDD (Test-Driven Development) и входит в семейство фрейморков для тестирования xUnit.

Главная идея данного фреймворка – “сначала тесты, потом код”. Это означает, что сначала мы определяем, что должно получиться в результате работы того или иного куска кода и пишем тесты, которые проверяют идентичность результата с требуемым, после чего пишем сам кусок кода, который и будем тестировать. Данный подход увеличивает эффективность работы разработчика и позволяет писать более стабильный код. В результате этого мы получаем меньшее количество времени, которое затрачивается на отладку программы.

Свойства JUnit

  • Фреймворк с открытым исходным кодом, который используется для написания и выполнения тестов.
  • Позволяет писать код более быстро и качественно.
  • Крайне прост в использовании.
  • Поддерживает аннотации для идентификации методов.
  • Поддерживает утверждения для тестирования получаемых результатов.
  • Тесты могут быть организованы  в связки тестов (test suites).
  • Имеет визуальную индикацию состояния тестов (красные – не пройдены, зелёные – пройдены).

Тестовый случай

Тестовый случай (Test Case) в юнит тестировании – это часть кода, которая проверяет ,что другая часть кода  (в частности – метод) работает в соответствии с определёнными требованиями.

Формально описанный тестовый случай характеризуется известными входными данными и ожидаемым выводом программы, который известен до начала выполнения теста.

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

На этом мы заканчиваем обзор фреймворка JUnit.

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

proselyte.net

Перевод книги The Art of Unit Testing / Хабр

Всем привет! Недавно я участвовал в попытке организации модульного тестирования в команде разработчиков. Как оказалось, для этого мне очень не хватает знаний и опыта. Т.к. у всех моих знакомых опыта примерно столько же, я решил начать восполнять пробел с прочтения книги The Art of Unit Testing (тыц тыц) — сложилось впечатление, что это «классика жанра» (ну, если даже php программисты ее рекомендуют).

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

Все отменяется. Я плохо искал, есть русская версия: www.ozon.ru/context/detail/id/26230428 Извините за беспокойство.

Я только-что залил книгу на notabenoid.com (это сервис коллективного перевода) и предлагаю всем желающим присоединиться к переводу. На хабре много людей, думаю, получится клево и относительно быстро.Welcome!

Пусть пост повисит немного (вдруг кто-то из него узнает об отличной книге), потом скрою. ЗЫ. Когда-то давно я участвовал в коллективном переводе Black Mesa (ремейке Half Life на движке Source). Когда после этого проходил ее — испытал офигенные ощущения! Особенно, когда встречал знакомые куски текста.

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

UPD2. Судя по доступным фрагментам русской версии, качество перевода оставляет желать лучшего.

UPD3. Английская версия в PDF 1drv.ms/1ggFMuR. Если Вам понравится, купите ее. На мой взгляд, книжка более полезна, чем деньги, за которые она продается.

habr.com

The Art of Unit Testing

Есть некоторые категории знаний, которые профессиональный разработчик познает в процессе своей работы, не прилагая к этому особенных дополнительных усилий. Вот, например, мало кто из нас читал замечательную книгу по регулярным выражениям Джеффри Фирддла, чтобы познакомиться с одноименной темой. Безусловно, есть масса людей, для которых «регвыры» стали смыслом жизни и без подобных фундаментальных знаний никак не обойтись. Но в большинстве случаев пары мелких статей и справки в соответствующем разделе документации будет достаточно для более или менее комфортной работы с регулярными выражениями (если такое понятие, как «комфортная работа» с регулярными выражениями вообще существуетJ).

Аналогичным образом мы обычно относимся и к изучению юнит тестирования. Ведь юнит-тесты – это же не rocket science; для их изучения не требуется многолетняя подготовка и множество бессонных ночей проведенных за изучением толстенных «талмудов» от гуру юнит-тестирования. Концепцию автоматизированного тестирования кода можно объяснить за 10 минут, а познакомившись с одним из тестовых фреймворков семейства xUnit (еще 15 минут), вы сможете работать с любым другим фреймворком практически сразу же. Затем нужно будет потратить еще 20 минут на изучение какого-нибудь изоляционного фреймворка, типа Rhino Mocks, и, вуаля, у нас есть еще один профессионал в области юнит-тестов.

Подобный уровень владения инструментом, подкрепленный опытом, прагматизмом и здравым смыслом, достаточен для комфортной работы, поэтому может сложиться впечатление, что опытному разработчику пользы от этой книги не будет никакой. Я, честно говоря, был такого же мнения и вряд ли заинтересовался бы этой книгой, если бы мне не пришлось готовить доклад по юнит-тестированию для наших американских коллег. Ведь одно дело - это владение вопросом для собственного использования, другое дело – это внедрение чего-то нового и изменения мировоззрения команды разработчиков, большая часть из которой является твоими боссами.

Забегая вперед, стоит сказать, что я заблуждался и книга The Art of Unit Testing by Roy Osherove будет полезна даже опытным разработчикам, но давайте обо всем по порядку.

Структура книги такова, что автор идет от наиболее простых и базовых понятий к более продвинутым вещам. Начинается все с простых примеров и определений, дается введение в TDD, рассказывается о «швах» приложения и об использовании «фейков», таких как моки и стабы, а также кратко описываются разные изоляционные фреймворки.

С самого начала Рой пытается вдолбить в голову читателя одну важную мысль: качественные тесты не менее важны, чем качественный production код! О том, что такое хорошие тесты, посвящена целая глава 7 The pillars of good tests, но даже за ее пределами тень «хороших» тестов будет преследовать читателя практически постоянно. О качестве кода написаны, наверное, десятки книг и бесчисленное множество статей; все мы знаем о том, как важно писать простой в сопровождении код и что делать для повышения его качества. Но к качеству тестов наше отношение зачастую не столь осмысленное, хотя плохие тесты могут испортить вам жизнь ничуть не хуже го$#о-кода в бизнес-логике.

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

Очень здорово, что помимо принципов юнит тестирования Рой уделяет внимание и таким важным аспектам, как внедрение юнит тестирования в организации, тестирование унаследованного (legacy) кода и влиянию тестов на дизайн приложения. В вопросах дизайна Рой считает, что testable дизайн обусловлен, прежде всего, ограничениями языка или среды программирования и не существует в динамических языках программирования (поскольку там мы «замокать» можем все, что угодно). Я с таким подходом не согласен, поскольку считаю, что хороший дизайн по умолчанию хорошо тестируем, и что возможность написания юнит тестов является хорошим признаком простоты контрактов классов и признаком того, что класс не берет на себя слишком много.

ПРИМЕЧАНИЕПодробнее об использовании юнит тестов как «лакмусовой бумажки» плохого дизайна можно почитать в заметке “Идеальная архитектура”.

По признанию самого Роя он потратил на написание книги 3 года - и это больше, чем он потратил на «создание» двух своих детейJ и периодически это чувствуется. Так, например, в разных местах книги используются разный формат диаграмм классов, иногда отличается наименование тестовых классов и методов, да и вообще, ощущение дежавю периодически посещает. Есть и другие мелкие замечания. Так, автор на протяжении двух сотен страниц использует стандартный синтаксис утверждений библиотеки NUnit, а с 200-й страницы, вдруг начинает использовать Assert.That и заявляет о том, что этот синтаксис более декларативен. Очевидно, что года через полтора после начала работы над книгой Рой добрался до этого синтаксиса, который ему понравился, а сил и времени на изменение предыдущих примеров уже не было.

Единственным существенным замечанием к этой книге является слабое раскрытие темы параметризованных юнит тестов. Да, Рой упоминает вскользь об этой возможности, но уж очень поверхностно и где-то ближе к концу книги. Чувствуется некоторая несправедливость, когда о том, что плохо рассчитывать на порядок запуска юнит тестов автор тратит 4 (!) страницы, а на параметризованные тесты, которые могут сэкономить массу времени и существенно повысить читабельность тестов, тратится от силы 2 абзаца.

Можно найти и другие моменты, в которых ваше мнение будет отличаться от мнения автора, но в целом, книга “The Art of Unit Testing” является одним из лучших источников информации по теме юнит тестирования, которая может либо изменить ваше мировоззрение в правильную сторону, либо обобщить и структурировать уже существующие знания.

Оценка: 4+

Дополнительные ссылки по теме
Книги
  • Подкасты
  • Статьи
  • sergeyteplyakov.blogspot.com

    The Art of Unit Testing / Хабр

    Есть некоторые категории знаний, которые профессиональный разработчик познает в процессе своей работы, не прилагая к этому особенных дополнительных усилий. Вот, например, мало кто из нас читал замечательную книгу по регулярным выражениям Джеффри Фирддла, чтобы познакомиться с одноименной темой. Безусловно, есть масса людей, для которых «регвыры» стали смыслом жизни и без подобных фундаментальных знаний никак не обойтись. Но в большинстве случаев пары мелких статей и справки в соответствующем разделе документации будет достаточно для более или менее комфортной работы с регулярными выражениями (если такое понятие, как «комфортная работа» с регулярными выражениями вообще существуетJ).

    Аналогичным образом мы обычно относимся и к изучению юнит тестирования. Ведь юнит-тесты – это же не rocket science; для их изучения не требуется многолетняя подготовка и множество бессонных ночей проведенных за изучением толстенных «талмудов» от гуру юнит-тестирования. Концепцию автоматизированного тестирования кода можно объяснить за 10 минут, а познакомившись с одним из тестовых фреймворков семейства xUnit (еще 15 минут), вы сможете работать с любым другим фреймворком практически сразу же. Затем нужно будет потратить еще 20 минут на изучение какого-нибудь изоляционного фреймворка, типа Rhino Mocks, и, вуаля, у нас есть еще один профессионал в области юнит-тестов.

    Подобный уровень владения инструментом, подкрепленный опытом, прагматизмом и здравым смыслом, достаточен для комфортной работы, поэтому может сложиться впечатление, что опытному разработчику пользы от этой книги не будет никакой. Я, честно говоря, был такого же мнения и вряд ли заинтересовался бы этой книгой, если бы мне не пришлось готовить доклад по юнит-тестированию для наших американских коллег. Ведь одно дело — это владение вопросом для собственного использования, другое дело – это внедрение чего-то нового и изменения мировоззрения команды разработчиков, большая часть из которой является твоими боссами.

    Забегая вперед, стоит сказать, что я заблуждался икнига The Art of Unit Testing by Roy Osherove будет полезна даже опытным разработчикам, но давайте обо всем по порядку.

    Структура книги такова, что автор идет от наиболее простых и базовых понятий к более продвинутым вещам. Начинается все с простых примеров и определений, дается введение в TDD, рассказывается о «швах» приложения и об использовании «фейков», таких как моки и стабы, а также кратко описываются разные изоляционные фреймворки.

    С самого начала Рой пытается вдолбить в голову читателя одну важную мысль: качественные тесты не менее важны, чем качественный production код! О том, что такое хорошие тесты, посвящена целая глава 7 The pillars of good tests, но даже за ее пределами тень «хороших» тестов будет преследовать читателя практически постоянно. О качестве кода написаны, наверное, десятки книг и бесчисленное множество статей; все мы знаем о том, как важно писать простой в сопровождении код и что делать для повышения его качества. Но к качеству тестов наше отношение зачастую не столь осмысленное, хотя плохие тесты могут испортить вам жизнь ничуть не хуже го$#о-кода в бизнес-логике.

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

    Очень здорово, что помимо принципов юнит тестирования Рой уделяет внимание и таким важным аспектам, как внедрение юнит тестирования в организации, тестирование унаследованного (legacy) кода и влиянию тестов на дизайн приложения. В вопросах дизайна Рой считает, что testable дизайн обусловлен, прежде всего, ограничениями языка или среды программирования и не существует в динамических языках программирования (поскольку там мы «замокать» можем все, что угодно). Я с таким подходом не согласен, поскольку считаю, что хороший дизайн по умолчанию хорошо тестируем, и что возможность написания юнит тестов является хорошим признаком простоты контрактов классов и признаком того, что класс не берет на себя слишком много.

    ПРИМЕЧАНИЕ Подробнее об использовании юнит тестов как «лакмусовой бумажки» плохого дизайна можно почитать в заметке “Идеальная архитектура”.

    По признанию самого Роя он потратил на написание книги 3 года — и это больше, чем он потратил на «создание» двух своих детейJ и периодически это чувствуется. Так, например, в разных местах книги используются разный формат диаграмм классов, иногда отличается наименование тестовых классов и методов, да и вообще, ощущение дежавю периодически посещает. Есть и другие мелкие замечания. Так, автор на протяжении двух сотен страниц использует стандартный синтаксис утверждений библиотеки NUnit, а с 200-й страницы, вдруг начинает использовать Assert.That и заявляет о том, что этот синтаксис более декларативен. Очевидно, что года через полтора после начала работы над книгой Рой добрался до этого синтаксиса, который ему понравился, а сил и времени на изменение предыдущих примеров уже не было.

    Единственным существенным замечанием к этой книге является слабое раскрытие темы параметризованных юнит тестов. Да, Рой упоминает вскользь об этой возможности, но уж очень поверхностно и где-то ближе к концу книги. Чувствуется некоторая несправедливость, когда о том, что плохо рассчитывать на порядок запуска юнит тестов автор тратит 4 (!) страницы, а на параметризованные тесты, которые могут сэкономить массу времени и существенно повысить читабельность тестов, тратится от силы 2 абзаца.

    Можно найти и другие моменты, в которых ваше мнение будет отличаться от мнения автора, но в целом, книга “The Art of Unit Testing” является одним из лучших источников информации по теме юнит тестирования, которая может либо изменить ваше мировоззрение в правильную сторону, либо обобщить и структурировать уже существующие знания.

    Оценка: 4+

    Дополнительные ссылки по теме
    КнигиThe Art of Unit Testing by Roy OsherovexUnit Test Patterns: Refactoring Test Code by Gerard MeszarosWorking Effectively with Legacy Code by Michael FeathersPragmatic Unit Testing in C# with NUnit, 2nd Edition by Andy Hunt and Dave ThomasПодкастыThe History of JUnit and the Future of Testing with Kent Beck Kent Beck, Developer Testing

    habr.com

    Java JUnit. Введение

    JUnit — библиотека для модульного тестирования программного обеспечения на языке Java. JUnit — простой и в то же время очень мощный инструмент для написания unit тестов. Подавляющее число компаний, разрабатывающих программное обеспечение на Java, используют именно JUnit на этапе разработки ПО.

    В данной статье мы будем рассматривать последнюю на данный момент версию JUnit, а именно 4.1.0. Скачать JUnit 4.1.0 можно тут.

    Для демонстрации основных возможностей JUnit Framework, напишем небольшой класс:

    public class Money {

         private int value;     private String type;

         public Money(int v, String t){          value = v;          type = t;     }

         public Money add(Money m){          return new Money(value + m.getValue(), type);     }

         public int getValue(){          return value;     }}

    Давайте для этого класса напишем тест:

    import static org.junit.Assert.*;import org.junit.Test;

    public class TestMoney {

         @Test     public void testAdd() {          Money m1 = new Money(12, "USD");          Money m2 = new Money(14, "USD");          Money expected = new Money(26, "USD");          Money result = m1.add(m2);          if(!result.equals(expected))               fail("Not equals");     }

    }

    Что мы здесь видим?

    Метод testAdd() будет проводить тестирование, так как на это указывает аннотация @Test. Данная аннотация всегда обозначает тестовые методы. Все методы тестирования обязательно являются public void. В данном методе создаются два объекта типа Деньги, имеющие значение Value 12 и 14 соответственно. Затем создается объект expected, которому присваивается ожидаемая сумма двух предыдущих объектов. Четвертому объекту типа Деньги присваивается фактическое значение, полученное после суммирования первых двух объектов методом add(int, String). Затем с помощью оператора if мы сравниваем ожидаемую и фактическую сумму, и если они не равны, с помощью метода fail(String) сообщаем об этом. Если в ходе unit тестирования будет достигнут метод fail, то весь тест считается заваленным и будет выведено сообщение Not equals.

    Поскольку в тесте таких проверок с оператором if может быть достаточно много, то чтобы не нагромождать код, более удобным представляется следующий способ:

    import static org.junit.Assert.*;import org.junit.Test;

    public class TestMoney {

         @Test          public void testAdd() {          Money m1 = new Money(12, "USD");          Money m2 = new Money(14, "USD");          Money expected = new Money(26, "USD");          Money result = m1.add(m2);          assertTrue(expected.equals(result));     }

    }

    В данном случае, если выражение expected.equals(result) вернет true, то тест будет пройден, иначе — тест считается заваленным.

    Помимо assertTrue JUnit предлагает много других способов проверки:

    import static org.junit.Assert.*;import org.junit.Test;

    public class TestMoney {

         @Test     public void testAdd() {          Money m1 = new Money(12, "USD");          Money m2 = new Money(14, "USD");          Money expected = new Money(26, "USD");          Money result = m1.add(m2);          assertFalse(!expected.equals(result)); // Если true - то тест завален          assertEquals(expected, result); // Если не равны - тест завален          assertNotNull(new Money(10, "USD")); // Если null - тест завален          assertNull(new Money(10, "USD")); // Если не null - тест завален          assertNotSame(expected, result); // Если оба объекта являются одинаковыми(не одно и то же, что равны) - тест завален          assertSame(expected, result); // Если оба объекта не являются одинаковыми - тест завален     }

    }

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

    assertEquals("Error", expected, result);

    Если бы у нас в классе Money была бы вот такая функция:

    public Money div(Money m){     return new Money(value / m.getValue(), type);}

    То вполне ожидаемо было проверить, выбрасывается ли исключение, если мы бы делили на 0. Это можно сделать следующим способом:

    @Test(expected = Exception.class)public void testDiv(){     Money m1 = new Money(12, "USD");     Money m2 = new Money(0, "USD");     Money result = m1.div(m2);}

    Как видите для этого мы создали отдельный метод тестирования (Собственно, рекомендуется для каждой тестируемой функции создавать отдельную функцию тестирования). В аннотации помимо @Test мы указали в скобках expected = Exception.class. Это означает, что мы ждем выброса исключения Exception, и если он не будет выброшен, то такое поведение тестируемой функции — неверное(мы явно указали, что m2 в поле value будет иметь 0), а значит тест будет завален.

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

    @Beforepublic void setup(){     Money m1 = new Money(12, "USD");     Money m2 = new Money(14, "USD");}

    Таких методов с @Before может быть несколько, но все они должны быть public void и будут выполнятся до всех тестов по очереди. Если после тестирования нам необходимо также произвести некоторые действия, то это также делается в отдельной функции с аннотацией @After. Также есть такие аннотации, как @BeforeClass, @AfterClass — они будут вызваны до и после создания экземпляра тест-класса соответственно и обязательно должны быть public static void. Помимо этого есть также очень интересная аннотация @Test(timeout = 1000). По истечении указанного в скобках времени, если тест не пройден, он считается заваленным. Время указывается в миллисекундах.

    Если какой-либо тест по какой-либо серьезной причине нужно отключить (например, этот тест постоянно валится, а исправлять его пока некогда) его можно зааннотировать @Ignore:

    @[email protected](timeout = 1000)public void testAdd() {     //код}

    Также, если поместить эту аннотацию на класс, то все тесты в этом классе будут отключены.

    Ну вот, почти все. Давайте только запустим созданный нами тест в среде Eclipse.

    Создайте Java Project и назовите его, например, JUnitExample. Создайте в папке src класс Money и поместите его в пакет main:

    package main;

    public class Money {     private int value;     private String type;

         public Money(int v, String t){          value = v;          type = t;     }

         public Money add(Money m){          return new Money(value + m.getValue(), type);     }

         public Money div(Money m){          return new Money(value / m.getValue(), type);     }

         public int getValue(){          return value;     }}

    Как правило, тесты помещаются в отдельную папку(Sourse Folder — папка с исходниками), а затем в пакет с тем же именем, что пакет тестируемого класса. Для этого кликните правой кнопкой по имени проекта и выберите пункт New->Source Folder. Дайте ей имя test и создайте в ней пакет main. Щелкаем правой кнопкой мыши на пакете main и выбираем New->JUnit Test Case(возможно данный пункт понадобиться найти в Other, но он там точно должен быть). Выберите имя для класса с тестами (как правило имя начинается со слова Test затем имя тестируемого класса). Пусть будет TestMoney. Здесь же можно поставить галочки напротив методов setUpBeforeClass(), tearDownAfterClass(), setUp(), tearDown() и Eclipse сам создаст методы с аннотациями @AfterClass, @BeforClass, @After, @Before. Далее кнопка ОК и описываем класс тестов:

    package main;

    import static org.junit.Assert.*;

    import org.junit.After;import org.junit.AfterClass;import org.junit.Before;import org.junit.BeforeClass;import org.junit.Test;

    public class TestMoney {     Money m1;     Money m2;     Money expected;     Money result;

         @BeforeClass     public static void setUpBeforeClass() throws Exception {     }

         @AfterClass     public static void tearDownAfterClass() throws Exception {     }

         @Before     public void setUp() throws Exception {          m1 = new Money(12, "USD");          m2 = new Money(14, "USD");          expected = new Money(26, "USD");          result = m1.add(m2);     }

         @After     public void tearDown() throws Exception {     }

         @Test     public void testAdd() {          assertEquals("Error", expected, result);     }}

    Для запуска нужно запустить программу в режиме Run As -> JUnit Test. После этого запустятся все тесты. На появившейся вкладке JUnit вы увидите результат.

    Скачать исходники: JUnitExample.ziphttp://javaxblog.ru/article/java-junit-1/

    alfalavista.ru

    Результат запроса: Книги по junit

    Тестирование Java-программ

    Тестирование Java-программ Алексей Владыкин 13 ноября 2015 Алексей Владыкин Тестирование Java-программ 13 ноября 2015 1 / 21 1 Основные идеи 2 Самотестирующийся код 3 Модульное тестирование JUnit Mockito

    Подробнее

    Тестирование Java-программ

    Тестирование Java-программ Алексей Владыкин 10 ноября 2014 Алексей Владыкин Тестирование Java-программ 10 ноября 2014 1 / 22 1 Основные идеи 2 Модульное тестирование JUnit FEST-Assert Mockito JaCoCo 3

    Подробнее

    Веб-сервисы средствами Netbeans 6.0

    Веб-сервисы средствами Netbeans 6.0 Хайруллин Ильяс Sun Campus Ambas s ador i l j - i l j @yandex. r u Повестка дня Что такое Netbeans? Поддержка Java EE 5 Что такое веб- сервисы? Демонстрация вебсервисов

    Подробнее

    Результат запроса: Книги по virtualbox

    Результат запроса: Книги по virtualbox VirtualBox 3.1: Beginner s Guide (11,3Мб) скачать книгу бесплатно без регистрации в формате pdf Название: Virtualbox и установка различных версий Windows Автор: Коллектив

    Подробнее

    Лебедев Андрей Сергеевич

    Лебедев Андрей Сергеевич Мужчина, 30 лет, родился 10 мая 1985 +7 (916) 598-40-83 [email protected] желаемый способ связи Skype: andremoniy Facebook: https://www.facebook.com/profile.php?id=100009335857530

    Подробнее

    ЖУРНАЛ НАУКОВИЙ ОГЛЯД 4 (25), 2016

    УДК 004:054 ГЛОБАЛЬНОЕ ПОЭТАПНОЕ ТЕСТИРОВАНИЕ ДЛЯ ANDROID ПРИЛОЖЕНИЙ Чоповенко А. О., Артемов А. О. Национальный технический университет Украины "Киевский политехнический институт", Украина, Киев В данной

    Подробнее

    Результат запроса: Журнал химия жизнь

    Результат запроса: Журнал химия жизнь Химия и Жизнь - Ежемесячный научно-популярный журнал, который в доступной форме объясняет. "Химия и жизнь" сле... >> Что бы такого съесть? Подборка о питании,. Про

    Подробнее

    jogo java para celular - speedx 3d - free download - 0 new files with jogo java para celular - speedx 3d found at 4shared. Start downloading jogo java para. 491684642749 24 дек 2011. Скачивайте Скачать

    Подробнее

    Путешествие без проблем! - Русско-испанский мини-разговорник скачать книгу бесплатно fb2, djvu, epub, pdf, txt для iphone, ipad

    Путешествие без проблем! - Русско-итальянский мини-разговорник скачать книгу бесплатно fb2, djvu, epub, pdf, txt на iphone, ipad и Android. 47954193693290 6 апр 2010. Описание: Серия разговорников Путешествие

    Подробнее

    Результат запроса: Журнал страна советов

    Результат запроса: Журнал страна советов Журнал Страна полезных советов - Журнал ваших советов, идей и секретов Конечно, очень хочется создать максимум комфорта и уюта в своем жилье, но стоит ли это. Страна

    Подробнее

    Результат запроса: Тексты в pdf формате

    Результат запроса: Тексты в pdf формате Текст в pdf формате. Чтобы редактировать тексты или извлекать цитаты для других. включает тексты.. Напечатанных форм в формате pdf без интерактивного ввода данных

    Подробнее

    Simple budget; Excel 2013. Any year calendar; Excel 2013. Ocean waves design presentation; PowerPoint 2013. 2013 Microsoft Corporation. All rights reserved. 60099755865 25 фев 2007. Microsoft PowerPoint

    Подробнее

    Результат запроса: Книги по fasm

    Результат запроса: Книги по fasm flat assembler (fasm) свободно распространяемый многопроходной. Отличный manual по fasm для. Sep 12, 2011 скачать книги по fasm Assembler. Хорошо поставленный вопрос это

    Подробнее

    СЕРИЯ ПРОСТО О СЛОЖНОМ СЕРИЯ

    СЕРИЯ ПРОСТО О СЛОЖНОМ СЕРИЯ Наука и Техника Санкт-Петербург 2016 Стрельцов В. А., Финкова М. А., Прокди Р. Г. Полезный СМАРТФОН и ПЛАНШЕТ на Android 2 книги в 1 Наука и Техника Санкт-Петербург 2016 Стрельцов

    Подробнее

    html счетчик отсчета

    html счетчик отсчета Как установить таймер обратного отсчета (счетчик) на сайт на любые html-страницы.в предыдущей статье про счетчик обратного отсчета (счетчик) на сайт - Duration: 8:48. Владислав Как

    Подробнее

    Результат запроса: Ли хунчжи книги

    Результат запроса: Ли хунчжи книги Книги, лекции и статьи основателя Фалунь Дафа,. 9 лекций Мастера Ли Хунчжи.... впервые публично представленная в Китае мастером Ли Хунчжи в 1992 году в. Язык книги. Все

    Подробнее

    Модульное тестирование на Java

    Модульное тестирование на Java Алексей Владыкин 11 ноября 2013 Алексей Владыкин Модульное тестирование на Java 11 ноября 2013 1 / 21 1 Основные идеи 2 JUnit 3 Java Logging API Алексей Владыкин Модульное

    Подробнее

    Поиск журналов, индексируемых в Scopus

    Инструкция по подбору журналов для публикации статей, входящих в библиографические и реферативные базы данных Scopus и Web of Science. Поиск журналов, индексируемых в Scopus Шаг 1. Поиск статей, индексируемых

    Подробнее

    [Пульмонология] Чучалин

    9 окт 2011. Скачать Чучалин А.Г. - Клинические рекомендации. Пульмонология, бесплатно, Книги, аудиокниги, журналы, видеоуроки, обучающее,. 421700680457681 У нас нашлось очень много книг по запросу пульмонология.

    Подробнее

    учебники в формате epub

    свободно пользователя структурные процессами пособия учебники в формате epub почтовый безопасности безопасность технических перезарядки. 875749756144740 Существуют два способа: 1. С ПК: Просто добавляем

    Подробнее

    УДК Иванов В. В., Иванов С.В., Иванов Вл.В.

    Секция 2 УДК 621.924.93 Иванов В. В., Иванов С.В., Иванов Вл.В. ИМИТАЦИОННОЕ МОДЕЛИРОВАНИЕ - РАБОЧИЙ ИНСТРУМЕНТ УПРАВЛЕНИЯ ПРОЦЕССОМ ГИДРОАБРАЗИВНОЙ ОБРАБОТКИ Саратовский государственный технический университет

    Подробнее

    Результат запроса: Олейник книги

    Результат запроса: Олейник книги Олейник Андрей. Книги онлайн перейти к книгам (1) Андрей Александрович Олейник - специалист. Борис Олейник. В нашей электронной библиотеке можно скачать книги автора Борис

    Подробнее

    Модульное тестирование на Java

    Модульное тестирование на Java Алексей Владыкин 28 ноября 2012 Алексей Владыкин Модульное тестирование на Java 28 ноября 2012 1 / 21 1 Основные идеи 2 JUnit 3 Mockito 4 Java Logging API Алексей Владыкин

    Подробнее

    docplayer.ru