 Hello, reactive way, it doesn't mean read and reduce, it means reactive programming. Our tests are pretty large, so we set it this way. First I would like to introduce you reactive programming, what it is about. Next I would like to introduce you how many parts of the testware are, and next I will describe them one by one. At the end I would like to share with you my shift of this approach over traditional one. And at the end I would like to present some piece of code, how it solves interesting problems in this game. Reactive programming, everything there is stream of values. You don't think about values, you think about streams. And reactive programming offers you a pile of methods to play with streams. You can transform them, you can merge them, you can aggregate them. For example, there is a method zip, two streams, one stream of shapes, and the second one is stream of colors. And the result is one stream of colored shapes. It helps you to play two variety asynchronous programs. It helps you to solve pretty interesting problems. For example, callback hell, and reactive testware, it's not just JUnit or TestNG test suite. It's a cooperation of three main players. First player is a test scenario. It runs in a system, and it's written in Python. And once you run the test scenario, systems start to produce some events, file system changes, network events, debas events, and so on. Next player is a testware broker. It's an application written in Node.js, and it collects all information from system, file system changes, messages from test scenario, start of scenario, for example, end of scenario, and provides them as a web socket services. The last part is test analysis. It uses reactive programming too. It's written in Python, and it waits for the right scenario to run, and starts collecting information from testware broker. And after the scenario stops, it verifies all data that came from test broker. Maybe, yeah, short demo, that's it. Yeah, green line, that's a system. Is it run here? I run one scenario there. It is BasityL3. So it runs command BasityL3. You see in a window with blue line that a few tests were run. Once I run the scenario, the right test verifications were run too, and start verifying. You see raw messages that came from testware broker. It's Firefox plugin for web socket, yeah, web socket client, and you see raw messages on a window below, yeah. You can repeat it again and again, and you see how tests are run again and again. Tests never end in stream of test verifications, and you see various tests, and finally I can run the whole test, I mean test suite, for example, for test suite, and test verification recognizes that it's the whole test suite, so it will generate a test engineer report at the end of the test suite run. You can run the test suite again, and test verification starts playing too, again. Main message of this demo is that your test, test verification is driven by test scenarios. So test verification doesn't play the system, it just waits for the right moment, where it starts verifying, yeah, that's the end of the demo. And now the players, test scenario, that's pattern script, that's small, and there is nothing, no verification there, it's small. It can be run, you can run it without tests, without test broker, just to run this pattern script. You see, for example, every scenario is described by named tuple, so you see values that are necessary to run the scenario. Basity L3, and it runs Basity L command with tree, and it lists both objects, provides the bus service, yeah, yeah, maybe another thing is, there is used simple dispatch, and that's run.register, so your register method run for this type of scenario. You can run the whole scenario. You see there are a lot of scenarios that are run, and you can see, maybe you can see the benefit of this, that I don't pay attention for verifications, for tests, so I can run test scenario in the right moment. I can sort the scenarios into the right order with respect to system state, yeah, so if you want to run something on unregistered system, you run scenarios that suppose that system is unregistered. Message broker, that's Node.js, it runs inside the system, yeah, it's a sort of message broker, yeah, but you know, we are testers, so we will not install RabbitMQ, for example, in a tester system. So it is simple application, and RxJS helps me very easy to solve those, to work. It offers a few streams, for example, you can observe file system changes, if you pay attention for file ETC, RHSN, RHSN.com, so you open web socket service with this URL and you see a lot of messages once file is changed. Debuss system events, if you want to validate that debuss works well. Testware monitor, main messages from test scenarios, start of scenario, end of scenario, run of command, result of command, for example, and you can see all web services in Firefox plug-in, yeah, so it's simple for me to see what's happening in a system. Test analysis, that's Python script, and here it is main, now the test needs to know what streams are important for verification, and yeah, first of all, I should say that this test verification will verify that once a user exchange config file, that scenario set can open URL, it verifies that the right configuration file was changed, and debuss event config changed, appears in a debuss object, com.redhead.RHSN1.config, yeah, so this test verifies how more parts of system plays together, yeah, this test needs to know something about debuss, so it will use debuss system monitor stream, it will use main testware monitor stream, and stream monitor RHSN1 to pay attention for file system changes, and next, it will wait for a scenario set can open URL, that's Python script that play with configuration file, and I think that's the main difference against traditional approach, that test is cooperation of three players now, so if you want to verify, to test something, so you will take a look at test scenarios, whether there is some scenario that plays, the use case, you want to verify, maybe you remember that in a demo, I ran one test scenario, and a few tests were run too, yeah, the same run, and different verifications were run, so is there some test scenario usable for me, if not, I will run new one, next question is, do I have all informations from test broker, if I want to verify network communication, I will extend testware broker easy way, to sniff network interface, and provide informations as a web socket service, and finally write test analysis, yeah, so now I would like to present you a piece of code about reactive programming, so this is a piece of code from test broker, and this code solves a problem with internal state, this code provides you a stream of open connections that want to use D-Bus system monitor, so every connection that opens URL D-Bus system monitor will be gathered together, and this stream offers a list of open connections, first of all connection stream, that's a stream of open connections, once a new connection appears, it emit a new value filter, it filters out connections that are open with URL, the right URL, and next the most important part is scan method, it's like reduce method, it takes accumulator and actual value, and inside you see that it appends actual value connection into a list, and at the end it filter out connections that are closed, that are not open, the difference between scan and reduce is that reduce provides you one value after stream is finished, yeah, and provides you every time once new value appears, it provides you actual state, yeah, it means a list of open connections, I like reactive programming, next piece, it is how to solve side effect, reactive programming helps you to solve side effects, what is side effect here, side effect here is sending of a response, you see it in the bottom of a code there is a subscribe method and there is a code that plays with input output, yeah, and there is a website.send, this is a code that sends a response back, yeah, and at the beginning of a code you see merging of all streams, it is stream that with file monitor, status, running of binaries, deep assistant monitors, all of those streams just create new data, no playing with no sending to websocket, no side effect, so you merge them into one stream, you filter out closed connections, and you subscribe and you do some side effect code, maybe you can imagine that if you use callbacks, so you have at the end of a callback some side effect method, for example, so this approach takes your callbacks out of a code into a higher level of code, this is the highest level of my code and I see results, so what do you think about it? I'm trying to present it because I'm new and I set this way in my team and I'm learning, even from you, how to explain this to my team and to other teams, how to use it. I'm a tester in my team because I have fun and I have free to write things, so thank you.