Онлајн тест за влез на Java. Програмско тестирање, JUnit. Јава тест предуслови

Верувам дека развојот на софтвер е повеќе од работа. Се гледам себеси како занаетчија кој се труди да биде подобар секој ден. „Најлесниот“ начин да го направите ова е да најдете некои добри алатки и да одговорите на следниве прашања:

• Кога треба да ја користам алатката X?
• Како треба да ја користам алатката X?

Автоматското тестирање е многу важен дел од развојот на софтверот, но има неколку објави на блоговите на програмерите за употребените алатки. Истата статија ќе ви овозможи да погледнете во мојата „кутија со алатки“. Ќе опфатам 12 библиотеки и рамки што ги користам за пишување на единици и тестови за интеграција и ќе дадам врски до страници за да ви помогнат да разберете како да ги користите.

Ајде да погледнеме во мојата кутија со алатки

Пред да можете да ги користите алатките опишани подолу, мора да поставите градба што автоматски ги извршува тестовите за интеграција и единици. Имам 2 забелешки на оваа тема:

• Тестирањето за интеграција со Maven опишува како можеме да поставиме изработка на Maven со тестови за интеграција и единици во посебни директориуми.
• Започнување со Gradle: Тестирањето за интеграција со приклучокот TestSets го опишува истото и за Gradle.

Сега сте подготвени да ги погледнете моите алатки одблизу. Ги поделив во категории за да ви биде полесно да се движите.

Значи, еве 12 алатки што ги користам за интеграција и тестирање на единици.

Водење тестови

AssertJ обезбедува флексибилен API за пишување тврдења со корисни пораки за грешка, ја подобрува читливоста на кодот за тестирање и ви овозможува да ги претворите тестовите во извршни спецификации кои се придржуваат до саканиот јазик специфичен за домен.

Дополнително:

• Користењето на Hamcrest за тестирање објаснува како да се користи Hamcrest за пишување тестови и како да се прошири со сопствени модули.
• Претворањето на тврдењата во јазик специфичен за домен објаснува како да креирате сопствени тврдења во AssertJ.
• Пишување чисти тестови: замена на тврдењата со јазик специфичен за домен. Објаснува зошто треба да ги замениме стандардните тврдења JUnit со наши кои го користат точниот јазик специфичен за доменот.

Тестирање на код за пристап до податоци

Брз DB, корисен за пишување тестови за интеграција што работат локална машинапрограмер.

Екстензија на JUnit што може да се користи за иницијализирање на базата на податоци до позната состојба пред да се изврши секој тест за интеграција и да се наполни базата на податоци со саканите податоци. DbUnit има свои недостатоци, но тоа е многу корисна алаткаА што ви овозможува да ги одделите податоците од тестот и кодот за тестирање.

Дополнително:

• ги опишува клучните компоненти на DbUnit што треба да ги знаете за да пишувате тестови користејќи DbUnit.
• дава пет правила за пишување на најдобри тестови за код за пристап до податоци.

Во потрага по тест задачи за java програмери, наидов на интересна страница (корисниците на Avast не треба да одат, откриен е скриптен тројанец, остатокот очигледно може) - http://www.betterprogrammer.com. Ги проверува квалификациите на Java програмерите со наједноставните, но автоматски: понуда за пишување неколку функции (методи) за зголемување на сложеноста и копирање на кодот во TextArea. Следно, моторот на страницата прави нешто со задачите (не друго освен тестирање на единицата), пресметува одреден индекс на квалификација според критериумите „брзина-квалитет“ и ја дава конечната проценка во оваа форма:

Потоа започнуваат прашањата. Јас самиот програмирав во Java по втор пат во мојот живот (и затоа само прескокнав сложени задачи), така што 82% на овој тест одговараат на нивото не-јава програмер. Колку тогаш треба да добијат Java Junior, Java Programmer и уште повеќе Java Senior? Од каков резултат да се очекува присутни java програмер - 90, 95, 99? И за крај, што ако „програмерот“ добие помалку од 82, но сепак конкурира за некаква работа?!

Тестирањето не е секогаш забавно и интересно. Овој процес обично е прилично долг и понекогаш полн со монотона работа. Се чини дека неодамна програмерите користеа стандарден излез или дебагер за тестирање на класите на Java.

Во оваа статија, ќе ја опишам библиотеката JUnit 4, која во голема мера го поедноставува и автоматизира процесот на пишување тестови.

За да ги демонстрираме главните карактеристики на JUnit Framework, ајде да напишеме примитивна класа во Java и да ја исмееме. Оваа класа ќе има два методи - наоѓање фактор на ненегативен број и збир од два броја. Дополнително, инстанцата на класата ќе содржи бројач за повици на метод.

Јавна класа MathFunc ( int повици; јавни int getCalls () ( враќаат повици; ) јавен долг фактор (int број) (повици ++; ако (број 1) (за (int i = 1; i

Сега да напишеме Unit тестови. За да го направите ова, ајде да создадеме класа со голем број методи за тестирање. Секако, класата може да ги содржи и вообичаените помошни методи. За да може тестирачот да одреди кој е кој, методите на тестирање мора да бидат означени со прибелешката @Test.

Прибелешката може да ги има следните параметри:

• очекувано - наведете кој исклучок ќе биде исфрлен со методот (видете го примерот подолу);
• тајмаут - по кое време во милисекунди да се запре извршувањето на тестот и да се смета за неуспешно.

Ако сакате да покажете дека одреден тест треба да се прескокне, тогаш напишете го со прибелешката @Ignore. Иако можете само да ја отстраните прибелешката @Test.

Се случува да ви треба некој контекст, на пример, претходно креирани примероци на класа, за да го извршите секое тест сценарио. И по извршувањето, треба да ги ослободите резервираните ресурси. Во овој случај, ќе ви требаат прибелешките @Before и @After. Методот означен со @Before ќе се изврши пред секој тест случај, а методот означен со @After ќе се изврши после секој тест случај.

Ако иницијализацијата и ослободувањето на ресурсите треба да се направат само еднаш - пред и по сите тестови, соодветно - тогаш користете пар забелешки @BeforeClass и @AfterClass.

И тука е самата тест класа со неколку тест скрипти:

Јавна класа MathFuncTest ( приватна MathFunc математика; @Before public 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(очекувано = IllegalArgumentException.class) јавна празнина factorialNegative() ( math.factorial(-1); ) @Ignore @Test public void todo() (assertTrue(math.plus(1, 1) == 3); ) )

Методот на повици ја тестира исправноста на бројачот на повици. Факториалниот метод проверува дали факторот е правилно пресметан за некои стандардни вредности. Факторисконегативниот метод проверува дали ќе се фрли незаконски аргументи исклучок за негативните вредности на факотријалот. Методот todo ќе биде игнориран. Размислете за отстранување на прибелешката @Ignore додека експериментирате со кодот.

Методот assertTrue проверува дали резултатот од изразот е вистинит. Некои други методи кои би можеле да ви бидат корисни:

• assertEquals - очекуваниот резултат и добиениот резултат се исти;
• assertNull - резултатот од изразот е нула;
• assertNotNull - резултатот од изразот не е нула;
• assertSame - очекуваните и примените објекти се ист објект.
• не успее - методот генерира исклучок на AssertionError - го додаваме таму каде што извршувањето на програмата не треба да достигне.

Во нашата модерен свет IDE-ите можат да најдат и лесно да извршат тестови во проект. Но, што ако сакате да ги извршите рачно користејќи програмски код. За да го направите ова, можете да го користите Runner "th. Постојат текст - junit.textui.TestRunner, графички верзии - junit.swingui.TestRunner, junit.awtui.TestRunner.

Но, малку повеќе модерен методе употребата на класата JUnitCore. Додајте го следниов главен метод во класата MathFuncTest:

Јавна статичка празнина main(String args) фрла Исклучок ( JUnitCore тркач = нов 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. Тогаш беше неопходно да се дефинира конструктор кој како параметар зема Стринг - името на методот - и да го предаде на матичната класа. Секој тест метод требаше да започне со префиксот за тестирање. Методите setUp и tearDown беа користени за иницијализирање и ослободување на ресурсите. Накратко, хорор. Па, сега сè е едноставно, да.

Тоа е се за денес. Сигурен сум дека JUnit Framework ќе ви помогне многу. Коментарите и прашањата за статијата се добредојдени.