- MySql алмаштыруу үчүн MariaDB аркылуу маалымат базасын интеграциялык тестирлөө
- Көп тилдүү колдонууну ишке ашыруу
- Файлдарды тиркемеге жана алар жөнүндө маалыматтарды маалымат базасына сактоо
Тесттин түрлөрү
сыноо деген эмне? Wiki айткандай: " Тест же тест бул системаны ар кандай кырдаалдарга жайгаштыруу жана андагы байкалуучу өзгөрүүлөргө көз салуу аркылуу системанын негизги процесстерин изилдөөнүн жолу." Башкача айтканда, бул белгилүү бир жагдайларда биздин системанын туура иштешин текшерүү.
Келгиле, тесттин кандай түрлөрү бар экенин карап көрөлү:
-
Бирдикти тестирлөө – бул системанын ар бир модулун өзүнчө сыноо болгон тесттер. Бул системанын минималдуу бөлүнүүчү бөлүктөрү болушу керек, мисалы, модулдар.
-
Системалык тестирлөө - бул колдонмонун чоңураак бөлүгүнүн же бүтүндөй системанын иштешин текшерүү үчүн жогорку деңгээлдеги тест.
-
Регрессиялык тестирлөө - жаңы функциялар же мүчүлүштүктөрдү оңдоолор колдонмонун учурдагы функционалдуулугуна таасир этеби же эски мүчүлүштүктөр кайра пайда болобу текшерүү үчүн колдонулган тест.
-
Функционалдык тестирлөө - бул тиркеменин бир бөлүгүнүн спецификацияларда, колдонуучунун окуяларында ж.б. айтылган талаптарга шайкештигин текшерүү.
Функционалдык тестирлөөнүн түрлөрү:
- тутумдун ички ишке ашырылышын билүү менен өтүнмөнүн бир бөлүгүнүн талаптарга ылайык келүүсүнө “ак куту” тести ;
- Системанын ички ишке ашырылышын билбестен, өтүнмөнүн бир бөлүгүнүн талаптарга ылайык келүүсүнө "кара куту" тести .
- Аткаруучулук тестирлөө - бул системанын же анын бир бөлүгүнүн белгилүү бир жүк астында иштөө ылдамдыгын аныктоо үчүн жазылган тесттердин бир түрү.
- Жүктөлгөн тестирлөө - стандарттык жүктөмдөрдүн астында системанын туруктуулугун текшерүү жана тиркеме туура иштеген максималдуу мүмкүн болгон чокусун табуу үчүн арналган тесттер.
- Стресс тестирлөө – стандарттуу эмес жүктөмдөрдүн астында тиркеменин иштешин текшерүү жана система кыйроого учурабай турган максималдуу мүмкүн болгон чокусун аныктоо үчүн арналган тестирлөөнүн бир түрү.
- Коопсуздук тести - системанын коопсуздугун текшерүү үчүн колдонулган тесттер (хакерлердин чабуулдарынан, вирустардан, жашыруун маалыматтарга уруксатсыз кирүүдөн жана жашоонун башка ырахаттарынан).
- Локалдаштыруу тести - бул колдонмо үчүн локалдаштыруу тести.
- Колдонуу жөндөмдүүлүгүн тестирлөө колдонуучулар үчүн колдонууга ыңгайлуулугун, түшүнүктүүлүгүн, жагымдуулугун жана үйрөнүүгө жөндөмдүүлүгүн текшерүүгө багытталган тестирлөөнүн бир түрү. Мунун баары жакшы угулат, бирок бул иш жүзүндө кантип иштейт? Бул жөнөкөй: Майк Кондун сыноо пирамидасы колдонулат:
-
Бирдик - тиркеменин ар кандай катмарларында колдонулган бирдик тесттери, тиркеменин эң кичине бөлүнүүчү логикасын текшерүү: мисалы, класс, бирок көбүнчө метод. Бул тесттер адатта тышкы логикадан мүмкүн болушунча обочолонтууга аракет кылат, башкача айтканда, тиркеменин калган бөлүгү стандарттык режимде иштеп жатат деген иллюзияны түзүүгө аракет кылат.
Бул сыноолор ар дайым көп болушу керек (башка түрлөргө караганда), алар кичинекей бөлүктөрүн сынашат жана өтө жеңил, көп ресурстарды талап кылbyte (ресурстар менен мен RAM жана убакытты билдирет).
-
Интеграция – интеграциялык тестирлөө. Ал системанын чоңураак бөлүктөрүн текшерет, башкача айтканда, бул логиканын бир нече бөлүктөрүнүн айкалышы (бир нече ыкмалар же класстар), же тышкы компонент менен иштөөнүн тууралыгы. Бул сыноолор бирдик сыноолоруна караганда азыраак болот, анткени алар оор.
Интеграция тесттеринин мисалы катары, сиз маалымат базасына туташуу жана аны менен иштөө ыкмаларынын туура аткарылышын текшерүүнү карай аласыз .
-
UI - колдонуучунун интерфейсинин иштешин текшерүүчү тесттер. Алар тиркеменин бардык деңгээлдеринде логикага таасир этет, ошондуктан аларды аягына чейин деп да аташат. Эреже катары, алардын саны азыраак, анткени алар эң оор жана эң керектүү (колдонулган) жолдорду текшериши керек.
Жогорудагы сүрөттө биз үч бурчтуктун ар кандай бөлүктөрүнүн аянттарынын катышын көрөбүз: реалдуу иште бул сыноолордун санында болжол менен бирдей пропорция сакталат.
Бүгүн биз эң көп колдонулган тесттерди - бирдик тесттерин кылдат карап чыгабыз, анткени бардык өзүн-өзү сыйлаган Java иштеп чыгуучулар аларды базалык деңгээлде колдоно алышы керек.
- JavaRush жана Habré боюнча Code Coverage жөнүндө материал ;
- негизги тест теориясы .
- Биз тестти жазып жатабыз.
- Биз тестти өткөрөбүз, ал өттүбү же жокпу (биз баары кызыл экенин көрүп жатабыз - коркпогула: ушундай болушу керек).
- Биз бул сыноону канааттандыра турган codeду кошобуз (тестти иштетиңиз).
- Биз codeду кайра түзөбүз.
- Текшере турган маалыматтарды көрсөтүү (түзмөктөр).
- Сыноодогу codeду колдонуу (сыноодогу ыкманы чакыруу).
- Натыйжаларды текшерүү жана күтүлгөндөр менен салыштыруу.
assertEquals(Object expecteds, Object actuals)— берилүүчү an objectилердин бирдей экендигин текшерет.assertTrue(boolean flag)— берилген маани чындыкка кайтарылганын текшерет.assertFalse(boolean flag)— берилген маани жалган экенин текшерет.assertNull(Object object)– an objectтин нөл экенин текшерет.assertSame(Object firstObject, Object secondObject)— өткөн баалуулуктар бир эле an objectке тиешелүү экендигин текшерет.assertThat(T t, Matcher<T> matcher)— t дал келүүчүдө көрсөтүлгөн шартты канааттандырарын текшерет.
Бул пирамиданын жөнөкөйлөштүрүлгөн versionсы: азыр ал кичинекей бөлүктөргө бөлүнгөн. Бирок бүгүн биз бурмалап, эң жөнөкөй вариантты карап чыгабыз.
Бирдикти сыноонун негизги түшүнүктөрү
Сыноо камтуусу (Code Coverage) өтүнмө тестирлөөнүн сапатына негизги баа берүүнүн бири болуп саналат. Бул тесттер менен камтылган codeдун пайызы (0-100%). Практикада көп адамдар бул пайыздын артынан куушат, мен макул эмесмин, анткени алар керек эмес жерлерде тесттерди кошо башташат. Мисалы, биздин кызматта кошумча логикасы жок стандарттуу CRUD (түзүү/алуу/жаңыртуу/жок кылуу) операциялары бар. Бул ыкмалар репозиторий менен иштеген катмарга ишти тапшырган ортомчулар. Бул жагдайда, биз текшере турган эч нерсе жок: балким, бул ыкма дао ыкмасын чакырат, бирок бул олуттуу эмес. Сынактын камтылышын баалоо үчүн, адатта, кошумча куралдар колдонулат: JaCoCo, Cobertura, Clover, Эмма ж.б. Бул маселени кененирээк изилдөө үчүн, бир нече ылайыктуу макалаларды сактаңыз:
Бул ыкма төмөнкү компоненттерден турат:
Сыноо этаптары
Сыноо үч этаптан турат:
Сыноонун модулдуулугун камсыз кылуу үчүн сиз колдонмонун башка катмарларынан обочолонушуңуз керек. Бул шпалдар, шылдың жана шпиондор аркылуу жасалышы мүмкүн. Мазактар - бул ыңгайлаштырылган an objectтер (мисалы, ар бир тестке мүнөздүү) жана биз алууну пландаштырган жооптор түрүндөгү ыкма чалууларына күтүүлөрдү коюуга мүмкүндүк берет. Күтүлгөн текшерүүлөр жасалма an objectтерге чалуу аркылуу ишке ашырылат. Stubs - тестирлөө учурунда чалууларга катуу жооп берет. Алар ошондой эле чалуу жөнүндө маалыматты сактай алат (мисалы, бул чалуулардын параметрлери же саны). Булар кээде өз термини менен аталат - шпион ( Spy ). Кээде бул терминдер чаташтырылып калат : айырмасы stub эч нерсени текшербейт, болгону берилген абалды окшоштурот . Мазак - бул күтүүлөр бар an object. Мисалы, берилген класстын ыкмасы белгилүү бир нече жолу чакырылышы керек. Башка сөз менен айтканда, сиздин тестиңиз такыр сынbyte, бирок шылдыңдан улам сынышы мүмкүн.
Сыноо чөйрөлөрү
Ошентип, эми бизнеске киришели. Java үчүн бир нече тестирлөө чөйрөлөрү (алHowтар) бар. Алардын эң популярдуусу JUnit жана TestNG. Биздин карап чыгуу үчүн биз колдонобуз:
JUnit тести - бул класста камтылган метод, ал сыноо үчүн гана колдонулат. Класс, адатта, аягында +Тест менен сынап жаткан класс менен бирдей аталат. Мисалы, CarService→ CarServiceTest. Maven куруу системасы автоматтык түрдө мындай класстарды сыноо аймагына камтыйт. Чынында, бул класс тест классы деп аталат. Негизги annotationларды бир аз карап көрөлү: @Test - бул методдун сыноо ыкмасы катары аныктамасы (чындыгында, бул annotation менен белгиленген ыкма бирдик тести). @Before - ар бир сыноонун алдында аткарыла турган ыкманы белгилейт. Мисалы, класстын тест маалыматтарын толтуруу, киргизилген маалыматтарды окуу ж.б. @After - ар бир сыноодон кийин чакырыла турган ыкманын үстүнө жайгаштырылган (маалыматтарды тазалоо, демейки маанилерди калыбына келтирүү). @BeforeClass - методдун үстүнө жайгаштырылган - @Before окшош. Бирок бул ыкма берилген класс үчүн бардык сыноолордун алдында бир гана жолу чакырылат жана ошондуктан статикалык болушу керек. Бул тест базасын көтөрүү сыяктуу оор операцияларды аткаруу үчүн колдонулат. @AfterClass @BeforeClass карама-каршы: берилген класс үчүн бир жолу аткарылган, бирок бардык сыноолордон кийин аткарылган. Мисалы, туруктуу ресурстарды тазалоо же маалымат базасынан ажыратуу үчүн колдонулат. @Ignore - төмөндөгү ыкма өчүрүлгөндүгүн жана жалпы тесттерди жүргүзүүдө көңүл бурулбай турганын белгилейт. Ал ар кандай учурларда колдонулат, мисалы, эгерде базалык ыкма өзгөртүлгөн болсо жана ал үчүн тестти кайра жасоого убакыт жок болсо. Мындай учурларда, ошондой эле сүрөттөмө кошуу сунушталат - @Ignore("Кээ бир сүрөттөмө"). @Test (күтүлгөн = Exception.class) - терс тесттер үчүн колдонулат. Бул ката болгон учурда методдун кандайча иш алып барарын текшерген тесттер, башкача айтканда, тест методдун кандайдыр бир өзгөчөлүктү таштоосун күтөт. Мындай ыкма @Test annotationсы менен белгиленет, бирок ката менен кармалат. @Test(timeout=100) - методдун 100 миллисекунддан ашпаган убакытта аткарылышын текшерет. @Mock - класс берилген an objectти шылдың катары коюу үчүн талаада колдонулат (бул Junit китепканасынан эмес, Mockitoдон) жана эгер бизге керек болсо, биз шылдың жүрүм-турумун белгилүү бир кырдаалда орнотобуз , түздөн-түз сыноо ыкмасы. @RunWith(MockitoJUnitRunner.class) - метод класстын үстүнө жайгаштырылган. Бул андагы тесттерди жүргүзүү үчүн баскыч. Жөө күлүктөр ар кандай болушу мүмкүн: мисалы, төмөнкүлөр бар: MockitoJUnitRunner, JUnitPlatform, SpringRunner, ж.б.). JUnit 5те @RunWith annotationсы күчтүүрөөк @ExtendWith annotationсына алмаштырылган. Келгиле, натыйжаларды салыштыруунун кээ бир ыкмаларын карап көрөлү:
assertThat(firstObject).isEqualTo(secondObject) Бул жерде мен негизги ыкмалар жөнүндө айттым, анткени калгандары жогоруда айтылгандардын ар кандай варианттары.
Сыноо практикасы
Эми жогорудагы материалды конкреттүү мисал менен карап көрөлү. Кызмат үчүн ыкманы сынап көрөбүз - жаңыртуу. Дао катмарын эске албайбыз, анткени ал биздин демейки. Тесттер үчүн баштоону кошолу:<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<version>2.2.2.RELEASE</version>
<scope>test</scope>
</dependency>@Service
@RequiredArgsConstructor
public class RobotServiceImpl implements RobotService {
private final RobotDAO robotDAO;
@Override
public Robot update(Long id, Robot robot) {
Robot found = robotDAO.findById(id);
return robotDAO.update(Robot.builder()
.id(id)
.name(robot.getName() != null ? robot.getName() : found.getName())
.cpu(robot.getCpu() != null ? robot.getCpu() : found.getCpu())
.producer(robot.getProducer() != null ? robot.getProducer() : found.getProducer())
.build());
}
}@RunWith(MockitoJUnitRunner.class)
public class RobotServiceImplTest {
@Mock
private RobotDAO robotDAO;
private RobotServiceImpl robotService;
private static Robot testRobot;
@BeforeClass
public static void prepareTestData() {
testRobot = Robot
.builder()
.id(123L)
.name("testRobotMolly")
.cpu("Intel Core i7-9700K")
.producer("China")
.build();
}
@Before
public void init() {
robotService = new RobotServiceImpl(robotDAO);
}@Test
public void updateTest() {
when(robotDAO.findById(any(Long.class))).thenReturn(testRobot);
when(robotDAO.update(any(Robot.class))).then(returnsFirstArg());
Robot robotForUpdate = Robot
.builder()
.name("Vally")
.cpu("AMD Ryzen 7 2700X")
.build();
Robot resultRobot = robotService.update(123L, robotForUpdate);
assertNotNull(resultRobot);
assertSame(resultRobot.getId(),testRobot.getId());
assertThat(resultRobot.getName()).isEqualTo(robotForUpdate.getName());
assertTrue(resultRobot.getCpu().equals(robotForUpdate.getCpu()));
assertEquals(resultRobot.getProducer(),testRobot.getProducer());
}
Келгиле, ишке киргизели: 
Тест жашыл, сиз дем чыгара аласыз)) Ошентип, кыскача айталы: тестирлөө codeдун сапатын жакшыртат жана иштеп чыгуу процессин ийкемдүү жана ишенимдүү кылат. Жүздөгөн класстык файлдар менен программалык камсыздоону кайра иштеп чыгууда канча күч жумшашыбыз керектигин элестетиңиз. Бардык бул класстар үчүн бирдик тесттери жазылгандан кийин, биз ишенимдүү түрдө рефакторлорду жасай алабыз. Эң негизгиси, бул иштеп чыгуу учурунда каталарды оңой табууга жардам берет. Балдар, бүгүн мен үчүн баары: лайк басып, комментарий жазгыла))) 
GO TO FULL VERSION