 OK, frequently Hello everyone. Ah, I'm Robert Carasek, I'm student from Slovakia, and today I will talk about next generation of warrocks. The main idea of this project was introduced by my mentor, he's a well know person in the community and warrocks community. And this new test suite was developed on Google summary of code internship. Mám hodně zvukovat škoda, tedy zděláme se na aplikativné věci. Ono zvukovat, že je to vyspět. Vyspět, že je to vyspět. Ať mám si to vytvěd, jestli je to na návět na věci. Ať mám si to vyspět, protože nejde na věci. Odpět, že je to u věci. Ať mám si to vyspět. Ať mám si to vyspět. skvělého správou byla s testovalová Lua Rockůho nevířskou. To bylo obči vním na niżém trasu nezapravěřeném scané dvění sodarů, kterýho chybíš jako se vyvířel s dvojším Lua Rockům. Na tohle je zvukovat. The script continues into tests, but you can't check the output of tests. If you make some error during the execution, the script will stop and you can't continue the other test. There are so many issues. Svěděl, že se v tomto všechny obyvěděl v dnech, takže se na to zámalo, že je to vždyšké zvukovat, které se nabijí, že je to nezvukovat, a že se to všechny obyvěděl, že je to zavědět, že je to závědět, že je to závědět. Prostě, takže se nabijí, které se na app věřili, a těchto věřili jsou na app věřili. Někdy návěřili, návěřili jsou věřili, které se na výmově věřili, takže jsou věřili těchto výmově věřili. Doste jsi nějaký idej, co jsme věřili, co jsme věřili, co jsme věřili? Jsem věřil, jsou jen je vidět ne Managerie, nesuppotik Энни glaubéte neersé z plotkem, ne risque jsme jen do rán sustain principle, nebo já mám hřichtitap. Protože nemohu se, díky má o modeledité, a je vycházit, je highlight tohle. Vyjedra těchIstí před výš delicé, chtěl po léstě. Bylo to na kováče systemu a servicí. Všechno nevědělo, že jsou tím, že vám se věděla vědělá vědělá text. To je tak vědělá, že je to vědělá, že je to vědělá, že je to vědělá, že je to vědělá, že je to vědělá, že je to vědělá. A to vědělá vědělá vědělá. Ideá for black box testing was the same in the new LVROKS test suite and Video environments stay same. There is one minimum, which has just basic modules for Warhawks and full environment got something like LWASC and others. We wanted to upgrade multi-platform, not just to make some trivial test on Appware. We wanted to run all test on Windows, not so all, but mostly which can be executed on Windows. First time I was like, why do we need to make this? Because I don't think command line users are executing it on Windows. During the summer, I saw every week some issues on Windows command line. So it's really working and people are using it on command line windows too. The best framework for making this happen was Bastit. It's, I think, most known unitesting framework in LWA. It's a multi-platform based on describe and eat blocks. I think every language has a similar framework. You can do asserts, mocks, asynchronous test, output, hand link, which is really good. You can implement your own library for that. For us, the best functionality is script execution before tests, because we built the environment before the tests. We want it all implemented in LWA, Bastit work with Moonscript 2 and the output languages you can change. Structure of new tests is really simple. The first folder is test, where there is LWA script for built environment. There is some small script to build Moxserver, which I say later, it was used for the Blackbox part of this project and to test upload functionality. Other subfolder is test files you can add there some rocks, specs for your project, for your unit test. Next folder is spec. This is like from documentation of Bastit framework. For each module you have a spec file with your unit tests. You can use tags on your unit tests. For example, we used some tests for windows, some tests for unix. Some special cases has a hashtag with the number of pull requests. If you are now developing some bigger part of LWA rocks and you want to pull your request, it's good to make a unit test for it. The test for first view, it looks like quite hacky, but in the main describe block you just write what you are going to test. As we can see, we are testing the install part of LWA rocks. The first test is just install LWasek module with skipping dependency checks. This is a Blackbox test, so you can imagine, you type it on your command line in your terminal. Something like LWA rocks install LWasek, you add your libraries, add your flags. These you assert in Bastit framework. For example, we can see if the environment is just minimal. We are not testing build of LWasek, so we test it like execute show LWasek. This should return false because LWasek is not in that environment. For better check, we check the library if there is something with LWasek. The next test, as I mentioned, was to sample request 631.2 and we can see that there is if condition, for example if there is Windows operating system. It's really easy, you can just open some test, read it for 5 minutes and you get into it. The mock of LWA rocks server was based on LWA rocks upload command because it's possible to test it with white box, but we want to stick the first idea test LWA rocks on Blackbox level. This is how we created some mock up server of LWA rocks. It's using rest server as module and has some basic get methods with the responses for your unit test. If you want test upload command on Blackbox level, unit creates some responses into this file. It runs in background during the execution. It could be executable on Travis, but it's not for Windows users. The biggest step for this test was to make it multi-platform. On OSX we don't have any big issues. There are some new if conditions, I think mostly for the WASOCAT module and the bigger problem was on Windows platform. You need to change quotes, some commands, rules in their command line. For example temporary directory, it's not the same and other problems. You can use it on AppWare or on your local Windows command line. You run mostly the main test on Windows 2 and get good coverage. But new issue was merging of these results. You get coverage from Travis and you get coverage from AppWare. There is no easy way. I don't know for sure, but last summer there was no way to how to merge these results on coveralls. So we changed the service to CodeCo. CodeCo is merging these results. It has some visual models to represent your coverage. So now if you send some pull request to Larox, it's going to CodeCo. Execution on Travis is on OSX, Unix. I think there are versions of Lua and Logit and on AppWare it's quite the same, but some tests are skipped. Funom issues, like I mentioned before, the rest of tests can be executed on Windows platform. We get into problem with Outpad on Windows. You don't see the consequence. You see the Outpad random and on AppWare is the same. We increased the coverage of Larox before it was less than 80%, now it's 88% of coverage. I think this is everything. And if you have any questions, yes, if you have any questions, please ask. And thank you. I have a question. Sorry if I missed that, but what's your target coverage? We didn't, the question was what was the target coverage. We had a goal to increase this coverage, but there wasn't some point. We need to get higher like 80 or something. We spent a lot of time on that Windows platform, so on that coverage I don't have so much time because we really created the new test for Larox just at the end phase of development. 80% is very good. The main functionality is covered by the black box test on two environments. What's left to be done for this project? Next to be done, so increased coverage. If you make some pull request, you should make some unit test for it to increase coverage to have more stable Larox build. I don't know, maybe fix some that Windows issues, but I'm more unit oriented, so I just do the basic on Windows really. It wasn't so easy. So you're looking for good Windows developer to help you? Yes, of course. This test suite is really using, so if you are a Larox developer, someone please make it better. I saw the web server, was it something called REST server? Yes, it was. You require a web REST server, but what is it? This is just a basic HTTP server. Question was... What is this REST server module? What is the REST server module? It's just a basic HTTP server, which is some kind of mock or some basic Larox server, because when you upload your modules to Larox, you need to get some response. You can mock it easy with busted on white box level, but if you want to make it like black box test, you need to have some HTTP server running behind. Is it the library that you use? Yes, yes. Is it part of Larox? It's another dependency. Before this test, this is some special test. Before this test, we built that server running in background, and test are executed, then we stop it, and that's the short description how it works. It's like you are sending something on Larox API1, some status of your modules, some upload of your new rock. Any questions? Thank you very much.