Кратки тестове за основите на java. Тестване на програми, JUnit
JUnit- библиотека за модулно тестване на Java програми. Създаден от Кент Бек и Ерик Гама, JUnit принадлежи към семейството на рамки xUnit за различни езици за програмиране, произхождащи от SUnit на Кент Бек за Smalltalk. JUnit създаде екосистема от разширения - JMock, EasyMock, DbUnit, HttpUnit и др.
Библиотека JUnitе пренесен на други езици, включително PHP (PHPUnit), C# (NUnit), Python (PyUnit), Fortran (fUnit), Delphi (DUnit), Free Pascal (FPCUnit), Perl (Test::Unit), C++ ( CPPUnit) , Flex (FlexUnit), JavaScript (JSUnit).
JUnit- Това е Java рамка за тестване, т.е. тестване на отделни секции от код, например методи или класове. Опитът, придобит по време на работа с JUnit, е важен при разработването на концепции за тестване на софтуер.
Пример за тест JUnit
Импортиране на org.junit.Test; импортирайте junit.framework.Assert; публичен клас MathTest ( @Test public void testEquals() ( Assert.assertEquals(4, 2 + 2); Assert.assertTrue(4 == 2 + 2); ) @Test public void testNotEquals() ( Assert.assertFalse(5 = = 2 + 2); ))
Трябва да използвате JUnit
JUnit ви позволява бързо да проверите дали вашият код работи по всяко време. Ако програмата не е много проста и включва много класове и методи, може да отнеме значително време, за да я проверите. Естествено, този процес е най-добре автоматизиран. Използване JUnitви позволява да проверите програмния код без много усилия и не отнема много време.
Единични тестовекласовете и функциите са вид документация за това, което се очаква в резултат на тяхното изпълнение. И не само документация, а документация, която може автоматично да проверява кода за съответствие с представените функции. Това е удобно и често тестовете се разработват както заедно, така и преди внедряването на класовете. Разработката, управлявана от тестове, е изключително популярна технология за създаване на сериозен софтуер.
Видове тестване и мястото на JUnit тестването в класификацията
Тестването на софтуер може да бъде разделено на два вида:
- тестване на черна кутия;
- тестване на бяла кутия.
При тестване на програма като черна кутия не се взема предвид вътрешната структура на приложението. Всичко, което има значение, е функционалността, която приложението трябва да предоставя. При тестване на програма като бяла кутия се взема предвид вътрешната структура, т.е. клас и методи. Освен това тестването може да бъде разделено на четири нива:
- единични тестове - тестване на отделни секции от код;
- интеграционно тестване - тестване на взаимодействието и съвместната работа на компонентите;
- тестване на системата - тестване на цялата система като цяло;
- приемно изпитване - окончателно изпитване на готовата система за съответствие с изискванията.
Unit тестването по дефиниция е тестване на бяла кутия.
Unit тестването се използва в две версии - JUnit 3 и JUnit 4. Нека разгледаме и двете версии, тъй като старите проекти все още използват версия 3, която поддържа Java 1.4.
JUnit 3
За да създадете тест, трябва да наследите тестовия клас TestCase, да замените методите setUp и tearDown, ако е необходимо, и най-важното, да разработите тестови методи, чиито имена трябва да започват със съкращението "test". Когато се изпълнява тест, първо се създава екземпляр на тестов клас (отделен екземпляр на класа за всеки тест в класа), след това се изпълнява методът setUp, стартира се самият тест и накрая се изпълнява методът tearDown. Ако някой от методите предизвика изключение, тестът е неуспешен.
Забележка: методите за изпитване трябва да са публично невалидни, може да са статични.
Тестовете се състоят от стартиране на някакъв код и проверка. Проверките най-често се правят с клас твърдятвъпреки че понякога се използва ключовата дума assert.
Като пример, разгледайте помощна програма за низове, която включва методи за проверка за празен низ и представяне на последователност от байтове като шестнадесетичен низ:
Публичният клас JUnit3StringUtilsTest разширява TestCase (частна финална карта toHexStringData = new HashMap(); защитената void setUp() хвърля изключение (toHexStringData.put("", нов байт); toHexStringData.put("01020d112d7f", нов байт(1,1,) 13,17,45,127)); toHexStringData.put("00fff21180" , нов байт(0,-1,-14,17,-128 )); //... ) protected void tearDown() хвърля изключение ( toHexStringData. clear(); ) public void testToHexString() ( за (Iterator iterator = toHexStringData.keySet().iterator(); iterator.hasNext();) (очакван краен низ = (String)iterator.next(); краен байт testData = (байт)toHexStringData.get(очакван);краен низ действителен = StringUtils.toHexString(testData);assertEquals(очакван, действителен); ) ) //... )
Допълнителни функции, TestSuite
JUnit 3 има няколко допълнителни функции. Например, можете да групирате тестове. За да направите това, трябва да използвате класа TestSuite:
Публичният клас JUnit3StringUtilsTestSuite разширява TestSuite ( public JUnit3StringUtilsTestSuite() ( addTestSuite(StringUtilsJUnit3Test.class); addTestSuite(OtherTest1.class); addTestSuite(OtherTest2.class); ) ) ) .
Можете да повторите теста няколко пъти. За това се използва RepeatedTest:
Публичният клас JUnit3StringUtilsRepeatedTest разширява RepeatedTest ( публичен JUnit3StringUtilsRepeatedTest() ( super(new JUnit3StringUtilsTest(), 100); ) )
Като наследите тестов клас от ExceptionTestCase, можете да проверите кода за генерирано изключение:
Публичният клас JUnit3StringUtilsExceptionTest разширява ExceptionTestCase ( публичен JUnit3StringUtilsExceptionTest(окончателно име на низ) ( super(name, NullPointerException.class); ) public void testToHexString() ( StringUtils.toHexString(null); ) )
Както можете да видите от примерите, всичко е доста просто и нищо повече - минимум код за JUnit тестване.
JUnit 4
JUnit 4 добавя поддръжка за нови функции от Java 5.0; тестовете могат да бъдат декларирани с помощта на анотации. В същото време има обратна съвместимост с предишната версия на рамката. Почти всички примери по-горе ще работят в JUnit 4 с изключение на RepeatedTest, който не е в новата версия.
Какви промени са въведени в JUnit 4? Помислете за същия пример, но с новите функции:
Публичният клас JUnit4StringUtilsTest разширява Assert ( частна окончателна карта
Какво се промени в JUnit 4?
- За да опростите работата, можете да наследите от класа твърдят, въпреки че това не е задължително.
- анотация @Предиобозначава методи, които ще бъдат извикани преди да се изпълнят тестовете. Методите трябва да бъдат публична празнота. Тук обикновено се поставят предварително зададени настройки за теста, в нашия случай това е генериране на тестови данни (метод setUpToHexStringData).
- Можете да използвате анотацията @BeforeClass, което обозначава методите, които ще бъдат извикани преди да бъде инстанциран тестовият клас; методи трябва да бъдат публична статична празнота. Има смисъл да се използва тази анотация (метод) за тестване, когато класът съдържа няколко теста, използващи различни предварително зададени настройки, или когато няколко теста използват едни и същи данни, за да не губите време за създаването им за всеки тест.
- анотация @Следобозначава методите, които ще бъдат извикани след като тестовете бъдат изпълнени. Методите трябва да бъдат публична празнота. Операциите за освобождаване след теста са поставени тук; в нашия случай - почистване на тестови данни (метод tearDownToHexStringData).
- анотация @След часоветесемантично свързани с @BeforeClass, но изпълнява методите след тестване на класа. Както в случая с @BeforeClass, методите трябва да бъдат публична статична празнота.
- анотация @Тестобозначава методи за изпитване. Както и преди, тези методи трябва да бъдат публична празнота. Ето и самите проверки. В допълнение, в тази анотация могат да се използват два параметъра, очакван - посочва очакваното изключение и изтичане - определя времето, след което тестът се счита за неуспешен.
Примери за използване на анотации с параметри, JUnit Test:
@Test(expected = NullPointerException.class) public void testToHexStringWrong() ( StringUtils.toHexString(null); ) @Test(timeout = 1000) public void infinity() ( while (true); )
Игнориране на изпълнението на теста, JUnit Игнориране
Ако някой от тестовете трябва да бъде деактивиран по някаква сериозна причина, например, тестът постоянно се проваля. Корекцията на теста може да бъде отложена до по-светло бъдеще чрез анотиране @Игнорирай. Ако поставите тази анотация в клас, тогава всички тестове в този клас ще бъдат деактивирани.
@Ignore @Test(timeout = 1000) public void infinity() ( while (true); )
Правила за тестване, правило JUnit
JUnitви позволява да използвате правила, дефинирани от разработчика преди и след изпълнението на теста, които разширяват функционалността. Например има вградени правила за задаване на изчакване за тест (Timeout), за задаване на очаквани изключения (ExpectedException), за работа с временни файлове (TemporaryFolder) и т.н.
За да декларирате правило, трябва да създадете общественоне статиченполе от тип, получено от MethodRule и го анотирайте с ключова дума правило.
Публичен клас JUnitOtherTest ( @Rule public final TemporaryFolder папка = new TemporaryFolder(); @Rule публичен окончателен Timeout = new Timeout(1000); @Rule публичен окончателен ExpectedException thrown = ExpectedException.none(); @Ignore @Test public void anotherInfinity( ) ( while (true); ) @Test public void testFileWriting() хвърля IOException ( final File log = folder.newFile("debug.log"); final FileWriter logWriter = new FileWriter(log); logWriter.append("Здравейте, "); logWriter.append("World!!!"); logWriter.flush(); logWriter.close(); ) @Test public void testExpectedException() хвърля IOException ( thrown.expect(NullPointerException.class); StringUtils.toHexString (нула); ) )
Тестови пакети, JUnit Suite, SuiteClasses
Пробното изпълнение може да бъде конфигурирано с анотация @RunWith. Тестовите класове, които съдържат тестови методи, могат да бъдат комбинирани в тестови пакети (Suite). Например, бяха създадени два класа за тестване на обекти: TestFilter, TestConnect. Тези два тестови класа могат да бъдат комбинирани в един тестов клас TestWidgets.java:
Пакет com.objects; import org.junit.runner.RunWith; импортирайте org.junit.runners.Suite; @RunWith(Suite.class) @Suite.SuiteClasses (( TestFilter.class, TestConnect.class )) публичен клас TestWidgets ()
За да персонализирате тестовете, които да се изпълняват, се използва анотацията @SuiteClasses, която включва тестови класове.
Абстрактни категории
анотация категорииви позволява да комбинирате тестове в категории (групи). За да направите това, тестът дефинира категорията @Категория, след което се конфигурират категориите за изпълнение на тестовете в Suite. Може да изглежда така:
Публичният клас JUnitStringUtilsCategoriesTest разширява Assert ( //... @Category (Unit.class) @Test public void testIsEmpty() ( //... ) //... ) @RunWith(Categories.class) @Categories.IncludeCategory ( Unit.class) @Suite.SuiteClasses (( JUnitOtherTest.class, JUnitStringUtilsCategoriesTest.class )) публичен клас JUnitTestSuite()
Анотация, JUnit параметризиран
анотация Параметризиранви позволява да използвате параметризирани тестове. За да направите това, в тестовия клас се декларира статичен метод, който връща списък с данни, които ще бъдат използвани като аргументи към конструктора на класа.
@RunWith(Parameterized.class) публичен клас JUnitStringUtilsParameterizedTest разширява Assert (частен окончателен CharSequence testData; частен краен булев очакван; публичен JUnitStringUtilsParameterizedTest(final CharSequence testData, окончателен boolean очакван) ( this.testData = очаквано тестване на @exp;expecTest; public void testIsEmpty () ( окончателен булев действителен = StringUtils.isEmpty (testData); assertEquals(очакван, действителен); ) @Parameterized.Parameters публичен статичен списък
Параметризиране на метода: Theories.class, DataPoints, DataPoint, Theory
анотация теориипараметризира тестовия метод, а не конструктора. Данните са маркирани с @DataPointsИ @DataPoint, метод на изпитване - използване @Теория. Тест, използващ тази функционалност, може да изглежда така:
@RunWith(Theories.class) публичен клас JUnitStringUtilsTheoryTest разширява Assert ( @DataPoints публичен статичен обект isEmptyData = нов обект ( ( "", true ), ( " ", false ), ( "някакъв низ", false ), ); @DataPoint публичен статичен обект nullData = нов обект ( null, true ); @Theory public void testEmpty(краен обект... testData) ( окончателен булев действителен = StringUtils.isEmpty ((CharSequence) testData); assertEquals(testData, действителен); ) )
Ред за изпълнение на теста
Ако трябва да изпълните теста в определен ред, можете да използвате анотацията @FixMethodOrder(MethodSorters.NAME_ASCENDING), дефинирана в JUnit 4.11. Например:
@FixMethodOrder(MethodSorters.NAME_ASCENDING) публичен клас MyTest ( @Test public void test01()(...) @Test public void test02()(...) ... @Test public void test09()(...) )
В противен случай могат да се използват следните 2 подхода.
Невалиден тест01(); невалиден тест02(); ... невалиден тест09(); @Test public void testOrder1() ( test1(); test3(); ) @Test(очакван = Exception.class) public void testOrder2() ( test2(); test3(); test1(); ) @Test(очакван = NullPointerException.class) public void testOrder3() ( test3(); test1(); test2(); )
@Test public void testAllOrders() ( за (Извадка на обект: permute(1, 2, 3)) ( за (Индекс на обект: проба) ( превключва (((Integer) index).intValue()) ( случай 1: test1( ); прекъсване; случай 2: тест2(); прекъсване; случай 3: тест3(); прекъсване; ) ) ) )
Списък на основните бележки
| анотация | Описание |
|---|---|
| @Тест публичен недействителен testMethod() |
методът е тест |
| @Тест (време изчакване=100) публичен недействителен testMethod() |
ако времето за изпълнение надвишава параметъра за изчакване, тогава тестът ще се провали |
| @Test(очаквано = MyException.class) публичен недействителен testMethod() |
методът трябва да хвърли изключение, принадлежащо на класа MyException, в противен случай тестът ще се провали |
| @Игнорирай публичен недействителен testMethod() |
игнорирайте тестовия метод |
| @BeforeClass |
метод, който се извиква веднъж за класа, преди да се изпълнят тестовите методи; тук можете да поставите инициализация, която трябва да се направи само веднъж, например, четене на данни, които да се използват в тестови методи или създаване на връзка с база данни |
| @След часовете публичен статичен невалиден testMethod() |
метод, който се извиква веднъж за класа, след като тестовите методи са били изпълнени; тук можете да поставите деинициализация, която трябва да се направи само веднъж, например да затворите връзката с базата данни или да изтриете данни, които вече не са необходими |
| @Преди публична статична недействителност предиMethod() |
метод, извикан преди всеки тестов метод в тестовия клас; тук можете да извършите необходимата инициализация, например да зададете първоначалните параметри |
| @След публична статична празнота afterMethod() |
метод, извикан след всеки тестов метод в тестовия клас; тук можете да извършите необходимата деинициализация, например да изтриете данни, които вече не са необходими |
Списък с типове Asserts
| Вид на проверката | Описание |
|---|---|
| неуспешно() неуспешно (низ съобщение) |
прекъсване на теста с грешка, т.е. тестът ще се провали |
| assertTrue (логично условие) assertTrue(java.lang.String съобщение, булево условие) |
проверете дали условието е равно на вярно |
| assertFalse (логично условие) assertFalse(низ съобщение, булево условие) |
проверка дали условието е равно на false |
| assertEquals(<тип>очакван,<тип>действително) assertEquals(низ съобщение,<тип>очакван,<тип>действително) |
проверка на равенството;<тип>е Object, int, double и т.н. |
| assertArrayEquals(очаквани байтове, действителни байтове) assertArrayEquals(низ съобщение,<тип>очаквания,<тип>действителни факти) |
проверка на масиви за равенство; подобно на assertEquals;<тип>е Object, int, double и т.н. |
| assertNotNull(обект обект) assertNotNull(низ съобщение, обект обект) |
проверка дали Обектът не е нулев |
| assertNull (обект обект) assertNull(низ съобщение, обект обект) |
проверка дали Обектът е нулев |
| assertSame(очакван обект, действителен обект) assertSame(низ съобщение, очакван обект, действителен обект) |
проверка за равенство на два обекта очакван и действителен, т.е. същия обект |
Пример за тестване на JUnit
За да демонстрираме основните характеристики на JUnit, използваме примитивния java клас FuncMath, който има два метода – намиране на факториала на неотрицателно число и сбора от две числа. В допълнение, екземплярът на класа ще съдържа брояч на извиквания на метод.
Публичен клас FuncMath ( int повиквания; public int getCalls() ( връщане на повиквания; ) публичен дълъг факториел (int номер) ( извиквания++; if (число< 0) throw new IllegalArgumentException(); long result = 1; if (number >1) ( за (int i = 1; i< = number; i++) result = result * i; } return result; } public long plus(int num1, int num2) { calls++; return num1 + num2; } }
Понякога всеки тестов сценарий се нуждае от някакъв контекст, като например предварително създадени екземпляри на клас, за да се изпълнява. И след изпълнение трябва да освободите запазените ресурси. В този случай се използват поясненията @Before и @After. Метод, маркиран с @Before, ще се изпълнява преди всеки тестов случай, а метод, маркиран с @After, ще се изпълнява след всеки тестов случай. Ако инициализацията и освобождаването на ресурси трябва да се извърши само веднъж - съответно преди и след всички тестове - тогава се използват двойка анотации @BeforeClass и @AfterClass.
Тестов клас с множество сценарии би изглеждал така:
Импортиране на org.junit.Test; import org.junit.After; import org.junit.Before; import org.junit.Assert; import org.junit.AfterClass; import org.junit.BeforeClass; публичният клас JUnit_funcMath разширява Assert ( private FuncMath math; @Преди публичен void init() (math = new FuncMath(); ) @After public void tearDown() (math = null; ) @Test public void calls() ( assertEquals(" math.getCalls() != 0", 0, dao.getConnection()); math.factorial(1); assertEquals(1, math.getCalls()); math.factorial(1); assertEquals(2, math. getCalls()); ) @Test public void factorial() ( assertTrue(math.factorial(0) == 1); assertTrue(math.factorial(1) == 1); assertTrue(math.factorial(5) ==) 120); ) @Test(expected = IllegalArgumentException.class) public void factorialNegative() ( math.factorial(-1); ) @Ignore @Test public void todo() ( assertTrue(math.plus(1, 1) == 3);))
Методът calls проверява коректността на брояча на повикванията. Факторният метод проверява дали факториалът е изчислен правилно за някои стандартни стойности. Методът factorialNegative проверява дали IllegalArgumentException ще бъде изхвърлено за отрицателни стойности на facotrial. Методът todo ще бъде игнориран.
В заключение трябва да се отбележи, че не всички възможности за използване на JUnit са представени в статията. Но както можете да видите от горните примери, рамката е доста лесна за използване, има малко допълнителни функции, но може да бъде разширена с помощта на правила и стартери.
В търсене на тестови задачи за Java програмисти попаднах на интересен сайт (Потребителите на Avast не трябва да ходят, открива се скриптиран троянски кон, останалите явно могат) - http://www.betterprogrammer.com. Той проверява квалификацията на Java програмистите по най-простия, но автоматичен начин: като предлага да се напишат няколко функции (методи) с нарастваща сложност и да се копира кодът в TextArea. След това двигателят на сайта прави нещо със задачите (не друго освен единично тестване), изчислява определен квалификационен индекс според критериите „скорост-качество“ и дава крайната оценка в тази форма:
След това започват въпросите. Аз самият програмирах на Java за втори път в живота си (и затова просто пропуснах сложни задачи), така че 82% от този тест отговарят на нивото не-java програмист. Колко тогава трябва да получат Java Junior, Java Programmer и още повече Java Senior? Какъв резултат да очаквате присъстват Java програмист - 90, 95, 99? И накрая, ами ако "програмистът" получи по-малко от 82, но все пак кандидатства за някаква работа?!
Вярвам, че разработването на софтуер е нещо повече от работа. Виждам себе си като занаятчия, който се опитва да бъде по-добър всеки ден. „Най-лесният“ начин да направите това е да намерите някои добри инструменти и да отговорите на следните въпроси:
- Кога трябва да използвам инструмента X?
- Как да използвам инструмента X?
Автоматизираното тестване е много важна част от разработката на софтуер, но има малко публикации в блоговете на програмистите за използваните инструменти. Същата статия ще ви позволи да разгледате моята "кутия с инструменти". Ще покрия 12 библиотеки и рамки, които използвам, за да пиша модулни и интеграционни тестове, и ще предоставя връзки към страници, за да ви помогна да разберете как да ги използвате.
Нека да надникнем в моята кутия с инструменти
Преди да можете да използвате инструментите, описани по-долу, трябва да настроите компилация, която автоматично изпълнява интеграционни и модулни тестове. Имам 2 бележки по тази тема:
- Тестването на интеграция с Maven описва как можем да настроим сборка на Maven с интеграция и модулни тестове в отделни директории.
- Първи стъпки с Gradle: Тестването на интеграция с приставката TestSets описва същото за Gradle.
Сега сте готови да разгледате по-отблизо моите инструменти. Разделих ги на категории, за да ви улесня при навигацията.
Ето 12 инструмента, които използвам за интеграция и тестване на модули.
Изпълнение на тестове
AssertJ предоставя гъвкав API за писане на твърдения с полезни съобщения за грешки, подобрява четимостта на тестовия код и ви позволява да превърнете тестовете в изпълними спецификации, които се придържат към желания език, специфичен за домейна.
Допълнително:
- Използването на Hamcrest за тестване обяснява как да използвате Hamcrest за писане на тестове и как да го разширите с персонализирани модули.
- Превръщането на твърденията в специфичен за домейн език обяснява как да създавате персонализирани твърдения в AssertJ.
- Писане на чисти тестове: Замяна на твърдения с език, специфичен за домейна. Обяснява защо трябва да заменим стандартните JUnit твърдения с нашите собствени, които използват правилния език, специфичен за домейна.
Тестване на код за достъп до данни
Бърза DB, полезна за писане на интеграционни тестове, които се изпълняват на локалната машина на разработчика.
Разширение към JUnit, което може да се използва за инициализиране на базата данни до известно състояние, преди да се изпълни всеки интеграционен тест и да се попълни базата данни с желаните данни. DbUnit има своите недостатъци, но е много полезен инструмент за разделяне на тестови данни и тестов код.
Допълнително:
- описва ключовите компоненти на DbUnit, които трябва да знаете, за да пишете тестове с помощта на DbUnit.
- предоставя пет правила за писане на най-добрите тестове за код за достъп до данни.
Java е обектно-ориентиран силно въведен език за програмиране, разработен от Sun Microsystems през 1991 г. Първоначално езикът се наричаше Oak и беше предназначен за програмиране на потребителска електроника, но по-късно беше преименуван на Java. Официалното издание на Java през 1995 г. се оказа много успешно и малко след това езикът Java зае силна позиция като инструмент за разработване на сървърни приложения.
В днешно време Java се използва във всички области на разработката на софтуер – сървърни приложения, настолни приложения, инструменти, уеб приложения – всичко се разработва с помощта на Java и свързаните с нея технологии.
Целева аудитория на Java теста
Java тестът съдържа въпроси, на които повечето разработчици с минимален опит в програмирането на Java знаят отговорите. Тестът ще бъде полезен за много хора, включително хора, които нямат много опит с Java и искат да получат минимално разбиране на основните концепции на този популярен език за програмиране. Също така, този тест може да бъде полезен за студенти, изучаващи Java, за да консолидират знанията, придобити в университети или в резултат на самостоятелна работа.
Предпоставки за тестване на Java
Предполага се, че преди да вземете теста за основите на Java, вие вече знаете основните понятия, като "променлива", "цикл", "метод" и знаете синтаксиса на основните езикови конструкции. В случай, че това не е така, препоръчваме първо да се запознаете с основите на Java, като прочетете уводния курс.
Структура на теста на Java
Тестът "Java - Fundamentals" обхваща следните теми:
Можете да прочетете повече за темите на тестовите въпроси по-долу:
- Обекти и класове: въпросите в тази тема обхващат такива понятия като клас, екземпляр на клас (обект), конструктори, методи и полета на клас.
- Синтаксис: Въпросите в този раздел ще тестват познанията по езикови ключови думи, оператори, основни типове (примитиви, низ), контролни конструкции (if-else, while, for) и разбиране на обработката на изключения (Exception).
- Друго: Този раздел съдържа въпроси относно основни понятия, термини и съкращения, конвенции за именуване на класове, променливи и методи. Също така в този раздел се разглеждат въпроси за файлове (.java, .class, .jar) и пакети, жизнения цикъл на обектите, събирането на боклука (събиране на боклук).
Полагането на онлайн тест за Java ви помага да тествате и засилвате знанията си за основите на Java, а също така ви кара да вземете по-трудните тестове в раздела за Java тестове.
Надяваме се, че този тест ще бъде полезен и забавен за вас.
По-нататъшно развитие на Java теста
Java тестът непрекъснато се актуализира с нови въпроси.
Екипът на Quizful планира да създаде тестове на експертно ниво в Java в близко бъдеще. Може би ще има тест за Java Puzzlers, но за съжаление той е много бавно изпълнен с въпроси.
Ако имате някакви коментари относно въпросите за теста, не забравяйте да ни пишете. Късмет.
Тестването не винаги е забавно и интересно. Този процес обикновено е доста дълъг и понякога пълен с монотонна работа. Изглежда, че съвсем наскоро програмистите са използвали стандартен изход или дебъгер за тестване на java класове.
В тази статия ще опиша библиотеката JUnit 4, която значително опростява и автоматизира процеса на писане на тестове.
За да демонстрираме основните характеристики на JUnit Framework, нека напишем примитивен клас в Java и да му се подиграем. Този клас ще има два метода - намиране на факториала на неотрицателно число и сбора от две числа. В допълнение, екземплярът на класа ще съдържа брояч на извиквания на метод.
Публичен клас MathFunc ( int повиквания; public int getCalls() ( връщане на повиквания; ) публичен дълъг факториел (int number) ( calls++; if (число 1) ( for (int i = 1; i
Сега нека напишем единични тестове. За да направите това, нека създадем клас с редица тестови методи. Естествено, класът може да съдържа и обичайните помощни методи. За да може участникът на теста да определи кой е кой, тестовите методи трябва да бъдат анотирани с анотацията @Test.
Анотацията може да има следните параметри:
- Очаквано - посочете кое изключение ще бъде изхвърлено от метода (вижте примера по-долу);
- timeout - след колко време в милисекунди да спре изпълнението на теста и да го отчете като неуспешно.
Ако искате да посочите, че определен тест трябва да бъде пропуснат, тогава го анотирайте с анотацията @Ignore. Въпреки че можете просто да премахнете анотацията @Test.
Случва се да се нуждаете от някакъв контекст, например, предварително създадени екземпляри на клас, за да изпълните всеки тестов сценарий. И след изпълнение трябва да освободите запазените ресурси. В този случай ще ви трябват анотациите @Before и @After. Метод, маркиран с @Before, ще се изпълнява преди всеки тестов случай, а метод, маркиран с @After, ще се изпълнява след всеки тестов случай.
Ако инициализацията и освобождаването на ресурси трябва да се извърши само веднъж - съответно преди и след всички тестове - тогава използвайте двойка анотации @BeforeClass и @AfterClass.
А ето и самия тестов клас с няколко тестови скрипта:
Публичен клас MathFuncTest ( частен MathFunc math; @Преди публичен void init() ( math = new MathFunc(); ) @After public void tearDown() (math = null; ) @Test public void calls() ( assertEquals(0, math .getCalls()); math.factorial(1); assertEquals(1, math.getCalls()); math.factorial(1); assertEquals(2, math.getCalls()); ) @Test public void factorial() ( assertTrue(math.factorial(0) == 1); assertTrue(math.factorial(1) == 1); assertTrue(math.factorial(5) == 120); ) @Test(expected = IllegalArgumentException.class) public void factorialNegative() ( math.factorial(-1); ) @Игнориране @Test public void todo() ( assertTrue(math.plus(1, 1) == 3); ) )
Методът calls проверява коректността на брояча на повикванията. Факторният метод проверява дали факториалът е изчислен правилно за някои стандартни стойности. Методът factorialNegative проверява дали IllegalArgumentException ще бъде изхвърлено за отрицателни стойности на facotrial. Методът todo ще бъде игнориран. Помислете за премахване на анотацията @Ignore, докато експериментирате с кода.
Методът assertTrue проверява дали резултатът от израз е верен. Някои други методи, които може да са полезни:
- assertEquals - очакваният резултат и получения резултат са еднакви;
- assertNull - резултатът от израза е null;
- assertNotNull - резултатът от израза не е null;
- assertSame - очакваният и получените обекти са един и същ обект.
- fail - методът генерира изключение AssertionError - добавяме го там, където изпълнението на програмата не трябва да достига.
В нашия съвременен свят IDE знаят как да намират и лесно да изпълняват тестове в проект. Но какво ще стане, ако искате да ги стартирате ръчно с помощта на програмен код. За да направите това, можете да използвате Runner "th. Има текст - junit.textui.TestRunner, графични версии - junit.swingui.TestRunner, junit.awtui.TestRunner.
Но малко по-модерен метод е използването на класа JUnitCore. Добавете следния основен метод към класа MathFuncTest:
Public static void main(String args) хвърля изключение ( JUnitCore runner = new JUnitCore(); Резултат = runner.run(MathFuncTest.class); System.out.println("извършване на тестове: " + result.getRunCount()); System.out.println("неуспешни тестове: " + result.getFailureCount()); System.out.println("игнорирани тестове: " + result.getIgnoreCount()); System.out.println("успех: " + резултат .беше успешно()); )
И резултатът от изпълнението:
Изпълнение на тестове: 3 неуспешни теста: 0 игнорирани тестове: 1 успех: вярно
В по-ранни версии на JUnit, за да напишете тестов клас, трябваше да създадете подклас на junit.framework.TestCase. След това беше необходимо да се дефинира конструктор, който приема като параметър String - името на метода - и да го предаде на родителския клас. Всеки тестов метод трябваше да започва с тестовия префикс. Методите setUp и tearDown бяха използвани за инициализиране и освобождаване на ресурси. Накратко, ужас. Е, сега всичко е просто, да.
Това е всичко за днес. Сигурен съм, че JUnit Framework ще ви помогне много. Коментари и въпроси относно статията са добре дошли.