Főoldal > Timetable > Session details > Contribution details

Közreműködés Előadás

Debreceni Egyetem - C terem
4. ALKALMAZÁSFEJLESZTÉSI ÉS ÜZEMELTETÉSI TECHNOLÓGIÁK

Viselkedjünk kérem! Azaz BDD bemutatása a Behat keretrendszeren keresztül

Előadók

  • DÉVAI Tamás

Elsődleges szerzők

Témakör

4.8 Alkalmazásfejlesztési technológiák , jövő Internet

Magyar nyelvű tematika (min. 1000 karakter, max. 2000 karakter)

Már a számítógépes technológia hőskorában is nagy fejfájást okozott mind a programozók, mind a megrendelőik számára hogy az elkészült programok megfelelő minőségűek és hatékonyak legyenek. Ezt hívjuk szoftver minőségbiztosításnak. Ez több részből áll: lennie kell a programnak egy pontos specifikációja, ami meghatározza hogy mit a pontos elvárások a programmal szemben és a program le legyen tesztelve minél több féle képpen, a lehető legtöbb teszt bemenettel. Nagyon sok féle tesztelés létezik: van kézi tesztelés, amikor egy vagy több ember a specifikációt követve, vagy anélkül kipróbálja a program összes funkcióját. Esetleg direkt hibásan használja azt. Ez azonkívül hogy elég költséges, nem megbízható és lassú is. Tesztelni lehet automatikusan is, amiből szintén rengeteg féle létezik. Léteznek un. unit tesztek, ekkor a program egyes atomi egységeinek működését teszteljük (egy függvényt). Ez is fontos, ettől azonban még lehet hogy az egyes részegységek kiválóan megfelelnek a velük szemben támasztott követelményeknek, viszont nem működnek együtt. Erre a problémára találták ki a funkcionális és integrációs teszteket. Az előbbi jól elkülöníthető program funkciókat tesztel az utóbbi pedig az egész programot vagy program rendszereket vizsgál működésük közben. Sok problémát okoz az ha kiderül hogy egy tervezési hiba csúszott a specifikációba, ami mondjuk egy teszt futása után derül ki. Ilyenkor a programozó kijavítja a tesztet és a programot, de a specifikációval már nem törölődik, hiszen annak karban tartása javítása nem az ő feladata. Tehát lesz egy súlyos inkonzisztencia a dokumentáció és a valós kód között. Ezen problémára nyújt megoldást a BDD, ahol egy emberi nyelvhez nagyon közeli leírónyel határozza meg mind a specifikációt, mind pedig magát a teszt esetet. Hogy ez hogyan néz ki a gyakorlatban, az előadásból megtudható.

Angol nyelvű előadáscím

Please, behave! That is, through the presentation of Behat BDD framework

Angol nyelvű tematika (min. 1000 karakter, max. 2000 karakter)

Already in the early days of computer technology also caused major headaches for both the programmers and the clients that the completed programs of adequate quality and effective. This is known as software quality assurance. It consists of several parts: the program must be an exact specification, which defines what the exact expectations for the program and download the program to be tested in as many different ways, the maximum number of test inputs. There are many types of testing: manual testing is when one or more people following the specifications, or without trying out all the functions of the program. It may mistakenly use it directly. This is in addition to be quite costly, unreliable and slow. To test can be automatically, of which there are also plenty of variety. There are so called. unit tests, then the operation of certain units of the atomic test program (a function). This is important, but even from that individual components can perfectly meet the requirements imposed on them, but do not work together. This problem was found in the integration and functional tests. The former is distinct program functions to test the latter to examine the entire program or a program during system operation. There are many causes of the problem if it turns out to be a mistake in the design spec, say that after a test run revealed. In this case, the programmer fixes and test the program, but the specification has not cleaned up as improve its maintenance was not his responsibility. So there will be a serious mismatch between the documentation and the actual code. BDD provides a solution to this problem in which a human language very close to describing the language as defined by the specification, as well as the test cases themselves. How this looks like in practice, you will learn the lecture.