Kategória: Automatizálás

  • Playwright & expect.poll

    Bár nagyon sokat használtam, mégsincs kéznel egy darab példa kódom sem ezzel kapcsolatban. Így hát a Playwright bibliát fogom segítségül hozni a példák bemutatására.

    Mire való?

    Nekem ez akkor volt nagyon hasznos, amikor API teszteket írtam, és a GET endpoint válaszánál nem volt elég egy 200-as válasz kód, mivel a háttérben a szinkronizációs folyamat nem ért be, tehát a GET endpoint-ot addig kellett hívni, amíg a megfelelő válasz meg nem érkezett.

    Elsőre én is, mint egy kis cserkész, betettem egy while loop-ba, és működött tökéletesen. Aztán rátaláltam a Playwright által támogatott gyári megoldásra, és azt kell mondanom, hogy zseniálisan jól működőtt.

    Példa kód a hivatalos oldalról

    await expect.poll(async () => {
      const response = await page.request.get('https://api.example.com');
      return response.status();
    }, {
      // Custom expect message for reporting, optional.
      message: 'make sure API eventually succeeds',
      // Poll for 10 seconds; defaults to 5 seconds. Pass 0 to disable timeout.
      timeout: 10000,
    }).toBe(200);

    Mi is történik itt? A GET endpoint válaszkódjával térünk vissza, és azt hasonlítjük össze az elvárttal. Teszük ezt addig, amíg tart a timeout-ban megadott érték.

    Következő példa: intervals

    await expect.poll(async () => {
      const response = await page.request.get('https://api.example.com');
      return response.status();
    }, {
      // Probe, wait 1s, probe, wait 2s, probe, wait 10s, probe, wait 10s, probe
      // ... Defaults to [100, 250, 500, 1000].
      intervals: [1_000, 2_000, 10_000],
      timeout: 60_000
    }).toBe(200);

    Ekkor az intervals-ban megadott értékek fogják jelenteni a próbálkozások közt eltelt időt. Ezt érdemes úgy beállítani, hogy lehetőleg ne generáljuk túl nagy extra terhelést a rendszer számára.

    Példa a soft-ra

    await expect.soft.poll(async () => {
      const response = await page.request.get('https://api.example.com');
      return response.status();
    }).toBe(200);

    Az expect.soft kapcsán nekem az a megélésem, hogy nagyon megoszlanak a vélemények. Vannak, akik teljes mértékben ellenzik a használatát, mások pedig – mint én is – úgy vannak vele, hogy vannak olyan esetek, amikor szükséges lehet. Ugye, soft esetén ha hibára fut, nem áll meg a futás, hanem megy tovább a teszt.

    Szóval nagyon hasznos tud lenni a Playwright online elérhető dokumentációja. Ha bármi kérdés merülne fel, ajánlom, hogy ott kezdödjön a kutatás.

  • Automatizáló framework-ök a szakmám során

    Eddigi pályafutásom során jó pár framework-höz volt szerencsém különféle programnyelvek mellett, és hát azt kell mondanom, hogy ideje ezeket összegyűjtenem, mert kezdem egy részét elfelejteni.

    • Selenium WebDriver (#C, JAVA)
    • HP UFT (Visual Basic Script)
    • Katalon Studio (Kotlin)
    • Cypress (JavaScript)
    • Playwright (TypeScript)

    Selenium + C# + NUnit

    Kezdjünk is bele. Szóval még az automatizáló pályám elején volt lehetőségem a munkám mellett gyakorolni, és az épp aktuális Selenium volt a választott C#-pal. Ez akkoriban azt jelentette, hogy ahogy ma egy demó kód kinéz, kb úgy irtam én is meg Visual Studioban, majd pedig NUnitban a saját gépemről futottak a tesztek. Attól függetlenül, hogy messze volt egy professziónális megoldástól, szépen fogta a regressziós hibákat.

    Valahogy így kell elképzelni, ahogy a tesztek futottak.

    HP UFT + Visual Basic Script + HP ALM

    Ez volt az első hivatalos automatizálós projektem, ami előtt még kaptam HP képzést is, bár ennél a munka és a szükséges tudás összeszedése internetről sokkal hasznosabbnak bizonyult. Ahogy nézem, a HP dolgai igencsak megváltoztak, más kezeli őket.

    HP ALM kapcsán a Gurunál találtam egy értékelhető leírást, és a jól emlékszem, én ennek az oldalnak használtam fel a tudásanyagát annak idején. Viszont jól látszik, hogy elszaladt az idő felette. Talán az egyik cimborám kérdezte pár éve, hogy mi a vélemenyem egy ilyen projektről, és már akkor azt mondtam, hogy kerülje el, mert nincs jövője.

    Annak idején ez az ökoszisztéma igencsak jól működött, bár ára is volt (cég fizette). Az ALM végezte a központosítást, az UFT pedig az automata tesztek fejlesztésért volt felelős.

    Így nézett ki az UFT.

    Az ALM pedig így.

    Szerintem ez a kettő együtt akkoriban zseniális párost alkotott.

    Katalon Studio

    Kísérletezgettem vele annak idején. Még tetszett is, de valahogy körülményesnek ítéltem meg a használatát. Ennél egy IDEs kódszerkesztővel jobban és minőségibben lehet/lehetett dolgozni. Az pozitív volt, hogy próbálta egy IDE-n belül kezelni a dolgokat, mint a HP UFT, viszont egy idő után kezdet átláthatatlanná válni számomra. Azóta egyébként valószínűleg ez is sokat fejlődött, bár nekem nem volt időm követni a változásokat.

    Valami ilyesmire emlékszem.

    Cypress + JavaScript

    Na ezt imádtam. Könnyedén és gyorsan lehetett benne dolgozni, bár csak 1 évet töltöttem vele. Egy negatívuma azért van/volt, hogy az async/await dolgokat maga kezeli. Ez az esetek túlnyomó többségében nagyon jól működik, de amikor valamiért ez nem jó, az fájdalmas tud lenni.

    Ha jól rémlik, én is VS Code-dal használtam, illetve GitLab-ban futottak a tesztek.

    Ha jól sejtem VS Codeban.

    Playwright + TypeScript

    Abszolút kedvenc. 3 évet töltöttem vele, és imádtam minden percet. Annyira könnyed és légies, és gyorsan lehet vele haladni annak köszönhetően, hogy zseniálisan van felépítve benne szinte minden, hogy csak ajánlani tudom.

    Több különböző nyelvet is támogat, bár nekem a TypeScript volt használatban. Illetve nagyon jól dokumentált. Nem volt szükség sok Google keresésre, mivel a leírás hozzá megválaszolt mindent.

    Ez pedig ilyen volt.

  • Java, Selenium és REST-Assured

    Ennek a bejegyzésnek nem a teljesség a célja, hanem, hogy egy rövid bemutatónk keresztül elkezdhető legyen egy JAVA-s project Seleniummal és/vagy REST-Assured-dal. A kód minősége sem arra készül, hogy ne lehessen belekötni, inkább, mint írtam csak egy könnyen átlátható példa az egész.

    IntelliJ IDEA

    Az IntelliJ IDEA egy kiemelt integrált fejlesztői környezet (IDE), amelyet elsősorban Java és Kotlin szoftverfejlesztéshez használnak. A JetBrains által fejlesztett központi munkaterületként működik, és olyan fejlett funkciókat kínál, mint az intelligens kódkiegészítés, a valós idejű hibaelemzés, az automatizált kódrefaktorálás, valamint a beépített eszközök teszteléshez, profilalkotáshoz és verziókövetéshez.

    Lépések Windows 10-en:

    • IntelliJ IDEA telepítés
    • JAVA futtató és fejlesztő (JDK) telepítés
    • Test Automation plugin
    • pom.xml fájl a függések telepítése miatt
    • első tesztek megírása

    Nézzük és akkor a lépéseket. Első körben töltsük le és telepítsük fel (alapértelmezett ajánlott) az IntelliJ IDEA-t. Majd pedig a számunkra megfeleőnek tűnő JAVA verziókat. Itt sem látom, hogy egy demó keretein belül miért térnék el az alapértelmezett telepítéstől, de el tudom képzelni, hogy más, tervezett rendszer esetén ez szükséges lehet.

    Nálam ez így néz ki:

    java -version
    java version "26.0.1" 2026-04-21
    Java(TM) SE Runtime Environment (build 26.0.1+8-34)
    Java HotSpot(TM) 64-Bit Server VM (build 26.0.1+8-34, mixed mode, sharing)
    
    javac --version
    javac 26.0.1

    Indítsuk el az IntelliJ IDEA-t majd pedig a File -> Settings -> Plugins alatt telepítsük fel a Test Automation-t a Marketplaceről. Erre azért van szükseg, hogy automatizációhoz szükséges projectek közül is könnyedén tudjunk a jövőben választani.

    Új project létrehozása: File -> New -> Project alatt történik.

    A teljesség igénye nélkül, itt van mód kiválasztani, hogy milyen legyen a project – nálam ugye ez Selenium – majd pedig a nyelvet – JAVA – , a build systemet – Maven -, ami a csomagok kezelését végzi, és számomra ez sokkal kézenfekvőbb, illetve a Test frameworkot – TestNG – ami persze hitvita lehetne, így nem mennék bele a választásom okába, végezetül pedig a JDK verziót, amit egyébként innen vezérelve le is tölthetünk, ha korábban nem tettük volna ezt meg.

    Apache Maven

    Az Apache Maven egy hatékony build automatizálási és projektmenedzsment eszköz, amelyet elsősorban Java alkalmazásokhoz használnak. Leegyszerűsíti a fejlesztést azáltal, hogy egy központosított konfigurációs fájl, a pom.xml (Project Object Model) segítségével kezeli a projekt függőségeit, fordítását, tesztelését és csomagolását. Főbb jellemzők Függőségkezelés: A Maven automatikusan letölti a szükséges könyvtárakat és a tőlük függő bővítményeket a központi online tárházakból, így megkíméli Önt a manuális könyvtárkezeléstől. Szabványosított struktúra: Egységes projektmappa-elrendezést biztosít (pl. src/main/java a kódhoz, src/test/java a tesztekhez), ami intuitívvá teszi a különböző projektek közötti navigációt. Építési életciklusok: A Maven előre definiált fázisokat tartalmaz, mint például a fordítás, tesztelés, csomagolás és telepítés, amelyek lehetővé teszik a szoftverek egységes építését egyszerű parancsokkal. Bővíthetőség: Funkcionalitása jelentősen skálázható az ökoszisztémában elérhető különféle építési bővítmények használatával. Hogyan működik Minden Maven projekt egy pom.xml fájlra támaszkodik, amely a könyvtár gyökerében található. Ez a fájl metaadatokat tartalmaz a projektről, annak külső függőségeiről, build utasításairól és bővítménykonfigurációiról. Amikor egy olyan parancsot futtatsz a terminálban, mint például az mvn clean package, a Maven beolvassa a pom.xml fájlt, letölti a hiányzó függőségeket a Maven Central Repository-ból, lefordítja a forráskódot, lefuttatja a teszteket, és az eredményeket terjeszthető formátumba, például JAR vagy WAR fájlba csomagolja. Források A kezdéshez tekintsd meg az Apache Maven dokumentációját a legújabb verziókról, vagy olvasd el a Telepítési útmutatót a gépeden történő beállításhoz.

    TestNG

    A TestNG egy hatékony, Java-alapú automatizált tesztelési keretrendszer (a név a Test Next Generation rövidítése), széles körben használt egység-, integrációs- és végpontok közötti (end-to-end) tesztekhez. A JUnit és NUnit keretrendszerekből merít inspirációt, de olyan fejlett funkciókat is tartalmaz, mint:Párhuzamos végrehajtás: Tesztek futtatása több szálon (akár metódus, osztály vagy lakosztály/suite szinten) a folyamat felgyorsítása folyamatban.Anotációk használata: Egyszerű kódcímkék (pl. @Test, @DataProvider)azonosítás. Adatvezérelt tesztelés a @DataProviosítás tesztelése vagy változók definiálása XML fájlokban.Csoport és függőségek: Tesztek logikai csoportokba rendezése és függőségek meghatározása a tesztelési sorrend biztosítására.Rendkívül népszerű választás keretrendszerek (pl. Selenium) automatizálásához, és könnyen integrálható olyan build eszközökkel, mint a Maven vagy a Gradle.

    POM fájl

    pom.xml

    <?xml version="1.0" encoding="UTF-8"?>
    <project xmlns="http://maven.apache.org/POM/4.0.0"
             xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
             xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
        <modelVersion>4.0.0</modelVersion>
    
        <groupId>org.example</groupId>
        <artifactId>selenium-java-testing</artifactId>
        <version>1.0-SNAPSHOT</version>
        <name>selenium-java-testing</name>
    
        <properties>
            <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
            <maven.compiler.target>17</maven.compiler.target>
            <maven.compiler.source>17</maven.compiler.source>
            <junit.version>5.11.3</junit.version>
        </properties>
    
        <dependencies>
            <dependency>
                <groupId>org.seleniumhq.selenium</groupId>
                <artifactId>selenium-java</artifactId>
                <version>4.25.0</version>
                <scope>test</scope>
            </dependency>
            <dependency>
                <groupId>org.assertj</groupId>
                <artifactId>assertj-core</artifactId>
                <version>3.26.3</version>
                <scope>test</scope>
            </dependency>
            <dependency>
                <groupId>org.junit.jupiter</groupId>
                <artifactId>junit-jupiter-api</artifactId>
                <version>${junit.version}</version>
                <scope>test</scope>
            </dependency>
            <dependency>
                <groupId>org.junit.jupiter</groupId>
                <artifactId>junit-jupiter-engine</artifactId>
                <version>${junit.version}</version>
                <scope>test</scope>
            </dependency>
            <!-- Source: https://mvnrepository.com/artifact/org.testng/testng -->
            <dependency>
                <groupId>org.testng</groupId>
                <artifactId>testng</artifactId>
                <version>7.12.0</version>
                <scope>test</scope>
            </dependency>
            <!-- Source: https://mvnrepository.com/artifact/io.rest-assured/rest-assured -->
            <dependency>
                <groupId>io.rest-assured</groupId>
                <artifactId>rest-assured</artifactId>
                <version>6.0.0</version>
                <scope>test</scope>
            </dependency>
            <!-- Source: https://mvnrepository.com/artifact/io.rest-assured/json-path -->
            <dependency>
                <groupId>io.rest-assured</groupId>
                <artifactId>json-path</artifactId>
                <version>6.0.0</version>
                <scope>compile</scope>
            </dependency>
            <!-- Source: https://mvnrepository.com/artifact/io.rest-assured/json-schema-validator -->
            <dependency>
                <groupId>io.rest-assured</groupId>
                <artifactId>json-schema-validator</artifactId>
                <version>6.0.0</version>
                <scope>compile</scope>
            </dependency>
            <!-- Source: https://mvnrepository.com/artifact/org.hamcrest/hamcrest -->
            <dependency>
                <groupId>org.hamcrest</groupId>
                <artifactId>hamcrest</artifactId>
                <version>3.0</version>
                <scope>test</scope>
            </dependency>
        </dependencies>
    </project>

    Selenium

    Selenium

    A Selenium WebDriver lehetővé teszi a böngészők közötti kompatibilitás tesztelését, és közvetlenül kommunikálva vezérli a böngészőket. Szinte minden programozási nyelvet támogat, beleértve a Java, Python, C#, Perl, Ruby és PHP nyelveket. A Selenium WebDriver a következő operációs rendszereket támogatja: Windows, Mac OS, Linux és Solaris.

    Az tesztem arra hivatott, hogy egy nagyon alap feladatot lásson el, miszerint elnavigál egy oldalra, név alapján rákattint a kártyára, majd pedig megvizsgálja, hogy a product page címe megfelel annak, ahová navigáltunk. Itt két dolgot akartam kipróbálni.

    Az egyik a DataProvider, ami jelen esetben egy tömb, ami adatvezérlőként működik, és a teszt az ebből kapott adatok alapján hajtódik végre.

    @DataProvider(name = "productData",...

    A másik pedig, hogy ezek a tesztek headless módban, párhúzamosan fussanak úgy, hogy ne akadjanak össze.

    ..., parallel = true)

    Ami ez utóbbinál fontos, hogy szálakra kell bontani a webdrivert, hogy azok a párhúzamos futás során ne üssék egymást, illetve szükséges egy testng.xml fájl néhány beállításhoz.

    private static final ThreadLocal<WebDriver> driver = new ThreadLocal<>();
    private static final ThreadLocal<MainPage> mainPage = new ThreadLocal<>();

    Párhúzamosítás, ahol .set(), vagy épp .get() metódusok használataval állítsjuk be, vagy épp erjük el a megfelelő szálunkat.

    MainPageTest
    package org.example.seleniumjavatesting;
    
    import org.openqa.selenium.WebDriver;
    import org.openqa.selenium.chrome.ChromeDriver;
    import org.openqa.selenium.chrome.ChromeOptions;
    import org.testng.Assert;
    import org.testng.annotations.*;
    
    import java.time.Duration;
    
    public class MainPageTest {
        private static final ThreadLocal<WebDriver> driver = new ThreadLocal<>();
        private static final ThreadLocal<MainPage> mainPage = new ThreadLocal<>();
    
        @BeforeMethod
        public void setUp() {
            ChromeOptions options = new ChromeOptions();
            options.addArguments("--headless=new");
            driver.set(new ChromeDriver(options));
            driver.get().manage().window().maximize();
            driver.get().manage().timeouts().implicitlyWait(Duration.ofSeconds(10));
            mainPage.set(new MainPage(driver.get()));
        }
    
        @AfterMethod
        public void tearDown() {
            if (driver.get() !=null) {
                driver.get().quit();
            }
        }
    
        @DataProvider(name = "productData", parallel = true)
        public Object[][] provideData() {
            return new Object[][] {
                    {"Fjallraven - Foldsack No. 1 Backpack, Fits 15 Laptops"},
                    {"Mens Casual Premium Slim Fit T-Shirts"},
                    {"Mens Cotton Jacket"}
            };
        }
    
        @Test(dataProvider = "productData")
        public void openProductPage(String productName) {
            // given
            mainPage.get().navigateToPage("/home");
    
            // when
            ProductPage productPage = mainPage.get().clickOnCard(mainPage.get().getCard(productName));
    
            // then
            Assert.assertEquals(productName, productPage.getProductName(), "Non the expected product page opens!");
        }
    }

    testng.xml
    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE suite SYSTEM "https://testng.org/testng-1.0.dtd">
    <suite data-provider-thread-count="3" name="MainPageTest">
        <test name="openProductPage">
            <classes>
                <class name="org.example.seleniumjavatesting.MainPageTest"/>
            </classes>
        </test> <!-- Test -->
    </suite> <!-- Suite -->

    Szálak száma: data-provider-thread-count="3"

    REST-Assured

    REST-Assured

    A REST Assured egy hatékony, nyílt forráskódú Java-alapú könyvtár, amellyel könnyedén tesztelhetők és validálhatók a RESTful API-k. Lehetővé teszi az HTTP kérések (GET, POST, PUT, DELETE stb.) küldését, és az eredmények (státuszkód, választest, fejlécek) elegáns, olvasható formában történő ellenőrzését.A REST Assured legfontosabb jellemzőiBolyhos (fluent) DSL szintaxis: Olyan, mintha angol nyelven írnád a tesztelési lépéseket, ami növeli a kód olvashatóságát és karbantarthatóságát.Integráció: Zökkenőmentesen beépíthető olyan Java keretrendszerekbe, mint a Maven, Gradle, JUnit vagy TestNG.Modern verziók: A 6.x verziók már a Java 17+ környezetet és a Spring 7 keretrendszert is támogatják.

    REST-Assured kapcsán pedig csak egy gyors kísérletezgetés implementációja látható, ami egy GET endpoint hívást hivatott tesztelni.

    ApiTesting
    package org.example.restassured;
    
    import io.restassured.RestAssured;
    import io.restassured.response.Response;
    import org.testng.Assert;
    import org.testng.annotations.Test;
    
    import static io.restassured.RestAssured.given;
    import static org.hamcrest.Matchers.equalTo;
    
    public class ApiTesting {
    
        @Test
        public void whenGet_thenOK() {
            Response response = RestAssured.get("https://ignav.com/api/openapi.json");
    
            Assert.assertEquals(response.statusCode(), 200);
            System.out.println("This is response: " + response.body().prettyPrint());
        }
    
        @Test
        public void whenGet_thenOK_logging() {
            given()
                    .baseUri("https://ignav.com/api")
                .when()
                    .get("/openapi.json")
                .then()
                    .statusCode(200)
                    .body("openapi", equalTo("3.1.0"))
                    .log()
                    .body();
        }
    }

    Folytatás várható, addig is itt van pár link, ami hasznos lehet a témában (Baeldung):

  • Playground avagy Playwright első lépései

    Elöljáróban annyit, hogy az itt elkészítésre kerülő dolgok nem éles rendszerhez készülnek, hanem csak kipróbálási célból, vagy épp arra, hogy segítséget nyújtsanak.

    Mint minden jó írás, én is próbálom azzal kezdeni az első ilyen típusú bejegyzést, hogy mik is azok az első lépések, amiket szükséges megtennünk ahhoz, hogy el tudjunk kezdeni, automata teszteket implementálni.

    Én mindezt Windows környezetben, és TypeScript alapon valósítom meg, ami GitHub-ban lesz tárolva, futtatva.

    Amire első körben szükségünk van, egy NodeJs telepítés, és lehetőleg abból is egy legújabb LTS változat. Ez a telepítés nem egy nagy kunszt, szimpla next, next, finish, viszont az egész alapja. Miután a telepítés végzett, egy node -v parancsot kiadva terminálban, meg tudunk győződni arról, hogy az adott verzió elérhető-e a gépünkön.

    Majd szükségünk lesz egy fejlesztő környezetre, amelyből én a Visual Studio Code-ot használom, mert számomra igencsak kézre áll. Letöltést követően ezt is könnyedén telepíthetjük.

    Most már majdnem adottak az alapok, hogy belekezdjünk a Playwright telepítésébe, de előtte én meg azt mondanám, hogy válaszuk ki a package managert is, és mivel jelenleg a pnpm az, ami új és előre mutató, így azt választom.

    A pnpm telepítésére nyissunk egy power shellt, majd pedig adjuk ki a következő parancsot: Invoke-WebRequest https://get.pnpm.io/install.ps1 -UseBasicParsing | Invoke-Expression.

    Majd pedig győződjünk meg róla, hogy létrejött a megfelelő bejegyzés a system environment variables-ben. Ha ez rendben, érdemes újraindítani a VS Code-ot, mielőtt folytatnánk a következő lépésekkel.

    Most pedig elkezdhetjük a Playwright telepítését. Először is hozzunk létre egy könyvtárat a számítógépen (amit később majd hozzáadunk egy Git repositoryhoz). Szóval nyissunk egy terminált, és adjuk ki a következő parancsot: pnpm create playwright. Miután a telepítés lefutott, pár kérdést kapunk, ahol, ha semmi nem mond ellent neki, válaszuk az alapértelmezett válaszokat, miszerint TypeScript, tests könyvtár, GitHub Actions workflow, Install Playwright browsers.

    Mit látunk most, ha megnyitjuk az explorert? Van egy playwright.config.ts fájlunk, ami a tesztekhez szükséges beállításokat tartalmazza. Van egy package.json és package-lock.json, amik a csomagkezelésért, parancsokért felelnek, illetve a már említett tests könyvtár, ahová az alap telepítés egy example.spec.ts fájlt hozott létre, amit le is tudunk futtatni, ezzel kipróbálni, hogy a telepítésünk sikeres volt.

    A következő parancsot terminálból kiadva tudjuk lefuttatni az összes tesztet (jelen pillanatban azt az egyet, ami alapból létrejött): pnpm exec playwright test.

    Miután a tesztek lefutottak, a pnpm exec playwright show-report parancs megnyitja a riportot, amin keresztül látni lehet, hogy pontosan milyen eredménnyel zárult a futás.

    UI Mode-ban is van mód futtatni és elemezni, erre a pnpm exec playwright test –ui parancs szolgál.

    A Playwright frissítése: pnpm install --save-dev @playwright/test@latest, a böngészők letöltése: pnpm exec playwright install --with-deps parancsokon keresztül történik.

    Végezetül pedig az aktuális Playwright verzióját igy nézhetjük meg: pnpm exec playwright –version.

    Az a helyzet, hogy maga a Playwright erre íródott oldala a legjobb forrás, ahonnan én is összeszedtem az információkat. Ezt érdemes lapozgatni, én eddig mindenre találtam megoldást benne.