 So, I was supposed to have a co-presenter for this talk. My name is Rahul Verma, let us get it out of the way. But I could not create profile for my co-presenter on his Islandia website, there was a technical difficulty in that. So, but then I need to have a co-presenter today, because this concept, first of all I do not understand you as audience. I do not know who you are, and you do not know who I am, and that is the reality. So, how many of you are from non-testing background, that you are not testers? How many of you are testers? How many of you are playing a testing role today, waiting to get out of it? Anybody like especially management executive positions, we should see those people that throughout the career they were developers or some other role, and today they are heading a testing team. We see those people, they do not understand testing, in the politest manner I want to say that. So, this presentation is an appeal, unless I am able to appeal to the emotional side of you, which is connected to testing profession. This presentation is not going to reach to you at all. This is not your usual test automation presentation. I am not that usual guy, because there are many of them in our country, and they are doing very well. They are much better people in talking about Selenium, Appium, DevOps, Pipelines, they are much, much better people than me to talk about that subject. I talk about fundamentals, I talk about the dignity of our profession, and somehow managed to make it technical. I code pride, I code philosophies, so let us see how that mix is going to happen, but before that, I will need to have my co-presenter here, because the first part of this presentation if I present it, it is not going to make sense. The problem with me is I do not know whether to address my co-presenter as he, she, it, I do not know the gender, I do not know how to address, what is the right now. So, anyways I will introduce my co-presenter. So, hello again, it is a role play, I am an automated test, so good afternoon. So, you are my creators, you could be a developer, if you think of unit test as an automated test, yes you are my creators, and I am your creation, and this is our story for the next 15 minutes. I was an idea in your mind, maybe from the beginning itself I was an idea of a coded manual test, test which you would code, or you were executing something me in a form called manual test, or exploratory test, and you thought it is a burden, I am taking too much of your time, and you do not have time for me, so you thought why not get rid of this guy, get rid of me, and you thought you have coded me, but you actually coded a part of me, you left your thinking outside of that code, and you thought you have gotten rid of me. So, in that cut down version, in that abstract version of my original form, I exist, but still I am happy, still I am managing, and you created many of us, I was not alone, I was not alone in that country, and we were different, we were so different, and in the difference is a beauty, we are beautiful because we are different, we are so different from each other, and when you created us, you acknowledged that we are different, that I am creating test one, the goal of this test one is would be this, this is the purpose, this is the eventual goal, but you ended up creating actually a lot of us, we had identities, we still are different, we still are beautiful, we still have identities, but not in your opinion and that is where the creator forgets its creation, and moves on, this is who we are, somebody said, I think it was Stalin, that a single death is a tragedy, a million death is a statistic, so single test has a personality, a million tests is a test bench, that is why you are looking at us, sheep, a flock of sheep, we could be different in ourselves, but in your opinion, okay thousand tests, I have to run them, that's who we are to you today, and you cage us, our only purpose is to lay green eggs, you break their eggs, and it doesn't matter to you, it's a donkey lion who, we need a green egg, somehow the test would manage it, and at the end of all this thing which you are doing to us, forgetting us, ignoring us, treating us like a herd that run this, run this, all the decisions are outside, there is a pipeline, there is this line, there is that line, there is the management, there is this percentage, you run, and after all of that, taking all our intelligence away from us, giving us no power of our own to decide, you know what you call us, you call us names, you say test automation is dumb, automated tests don't deliver, regression tests are just a safety net, they are useless, they don't find bugs, bugs are found using exploratory testing, automated testing is just a safety net, useless thing, just let them run, that's what we mean to you, but I was your first love, isn't it, you are about me, you are a tester, or you are playing a testing role, your life as a tester, the most important part of that was me, the test, but today you are caught up in all the rest of the noise, agile, scrum, code reviews, Jenkins, GitHub, everything apart from me is important for you today. In this conference, how many times did you talk about testing as a profession, or test as the important part, how many of you actually know test design techniques today, when did you pick up the last testing book, you might have picked a programming book, but when did you pick up a testing book, these are the realities, what you don't realize is that I am the water in the water, in Hinduism there is something called Advaithva, the consciousness in the world, there is no duality of consciousness, it's not Atma and Parmatma, everything is Parmatma, so the consciousness inside me is the consciousness, the consciousness inside you is the consciousness, this world consciousness is one, so if the drop in the ocean is meaningless to you, the ocean is meaningless, and that's what you're doing to test it, either I am meaningful or everything else is meaningless, if you don't treat me well, you see that's the reality, it's not just ignoring one test, you are ignoring all tests, you are ignoring the importance of automated test, it is just coding, it is some CI pipeline, some job, did the batch run, did the job run, did the herd go from one point to other and where are my green eggs, that's who we are, and this makes me wonder why do you ask me if I am a cat, you use test engines like test nj, you annotate me, you mark me at test, and at the run time you don't ask are you test, you say are you marked with at test, so that I can add you to my test queue, you don't let me express, if you had asked me I would have told you that I am a test, but you don't ask me, you tell me that you are a test, and that decision of telling that I am a test is also outside me, I don't tell that I am a test, you ask somebody else, is it a test, you don't ask me am I a cat, you ask somebody else to label me as a cat, and how, you don't let me handle myself, who am I, all the data about me, all the information about me, my name, my surname, my parents name, whom I depend on, who drives me, what is my purpose, everything is outside me, whatever things I could take decision on, so you see I can't control the universe, you are expressing the universe to me, I need to express back to the universe, but whatever information I needed to take that decision to express myself to the universe to you took away from me, and then you call me dumb, then you call me useless, there is a scene from Tarez Amipur, you remember, have you seen Tarez Amipur, that if there is a tree, very good green tree, and everyday you go to the tree and you keep cursing it, you are bad, you are dumb, you are bad, what happens to the tree, the tree is dead, that's what you are doing to test and testing, you entered into testing because you failed at something else, actually that is true for most of you, including Rahul, you couldn't become a developer, most of you, so you became a tester, but should that be your life story, should you hate, test so much, testing so much, isn't it time that you found your true love in testing and do something about it, rather than waiting to run away from it, waiting to run, waiting to open a restaurant somewhere, become a developer one day, become a data scientist, what is wrong with testing, nothing, the wrong thing is only that you don't feel dignified being a tester, so all the agilists, all these agile experts around the world and from India keep telling you, tester is not a role, everybody is a developer, do you have the guts to tell them, no, I am a tester, you can label me anything, but testing needs skills, you are killing the profession and you are killing me as a tester, what do I do, what drives me, who are my parents, I don't know about my parents, somebody else knows about my parents, some register somewhere outside, I don't know who my parent is and you expect me to be intelligent to take run time decisions, I cannot, you have taken away the power of my expression, what's my type, am I a performance test, functional test, do I run on chrome, Firefox, I don't have any mechanism to check at run time, who am I, you took away everything, you put it somewhere else and you want me to take it, you want me to be intelligent, you talk of artificial intelligence, data science, machine learning, but you are going to keep all of that outside me, outside me, you might have an intelligent library, but you would never have an intelligent test, you made me dumb, take some responses, which universe should I surrender, should I give up, is it an environment I should not be running, no, no, you would create your directories, you would create a directory, tests inside that you would say OS, Windows, Mac, Mac tests go here, you keep caging us, you don't ask me which operating system I was meant to run on, I can check what is the current operating system and then decide should I run or not, but you are happy caging me, which version of API, I could know that I am meant for version 1.1, you just need to tell me what is the current API version, I can decide that this is not the right version for me, I won't run, but even the power to surrender, to end my life span, you have taken away from me and then you release movies in which society is justified in all those court cases, but all your sympathy, empathy is outside me for everybody else, apart from the core of your profession, I was supposed to be your dearest friend and love, not anymore, if and only if you had decided it the other way around and just let me be what could have happened, so over to doubt, so this was the philosophical part, does it reach you, do you understand where we are getting, whenever the word test automation is used and I say test automation design, people assume that I am using test engine, if I am talking in Java, if I am talking in Python, people assume I am, Py.test is assumed, how long are you going to use these borrowed frameworks from developers, which test engine was created ever by a tester, name it, in the world, not India, in the world, with name single tester who has designed a test engine, these are unit testing frameworks, do you understand that, do you acknowledge that our testing needs are different from unit tests, unit tests are about efficiency, higher level tests needs are higher level, test engine was a replacement of J unit, when I said we need a new test engine, somebody said you are reinventing the wheel and I told them, so where are your wooden or stone wheels in your BMW today, somebody reinvented the wheel, so we have the wheels of today, reinvention is the need if you want to do better, you need to experiment, whatever I am going to show you, I am not here to sell, I anyways open source all my work, so do not think I am here to sell Arjuna, you are looking at the only user of Arjuna today and I am working on it for 4.5 years, so it is experimental, you can learn the concepts, take some part, full part, whatever you want to take, it is not perfect, I am a tester just like you, mechanical engineer entered into testing just the way most of us have entered and then found the value of testing along the way and to the point that when offers were coming my way to become something else, I said no, I have found myself, I am in a good profession, oh you are a good coder, you study design patterns, yes, so that I can become a better tester, I write more code than the average developer does in the world, I write a lot of code, but I write that code to serve in my profession, not to keep adding, you know, testers are ashamed today to put even the word tester in their LinkedIn heading, they are ok in writing something else, but the word tester should not come or if there is a tester, there should be S debt or something, S debt has become just like agile, it should be in the marketing brochure, internal realities everybody knows, I just wish that to become a great tester, we had to just stand up in the morning and for 15 minutes and say that we are a tester, testing is a deeper profession than that, much much deeper, it is 15 years, 16 years for me and my to-do list, I would retire and still not cover what all is needed for me to become a good tester, how can it be just another role, which anybody can do, we can have longer conversations on that, but I think I have expressed myself. So, I will introduce you to the concepts around things, Arjuna is open sourced, it is available out there, Apache licensed, you want to take it experiment, please go ahead experiment, you want to take the concepts from here or if I have tweaked your mind a little bit, please go ahead and experiment. I am not here to change anything, I am just here to appeal, please stop spitting at testing profession. As non-testers and as testers, that is my only appeal, humble appeal to you, my community guys. Because there are lot of people from testing community who are saying tester is a role, tester is not a job, testing is a job, you can sit with me and I will show it to you, you should sit with the person who loves testing, most of those conversations are happening amongst people who hate testing being a tester, we cannot help that. We are self victimizing guys, we have always victimized ourselves, we have changed roles and we played roles, we became the villains actually, we became the quality gate, the sign of guys, nobody asked us to do that. And I do not think so you know agile routes, but agile in the original version of agile, there is no place of tester or outsourced testing. So, it is an irony that in India how most of the outsourced testing companies or development companies have agile, they started doing this, I do not think so they understand agile, they have not gone through the document. I study these things, then I form opinions. It was years, years later that agile testing book came and in the name of testing, the only thing which is mentioned there is exploratory testing. It is a wonderful book by the way in general to learn, by Lisa Crispin and Janet Gregory. So, anyways I am a man of strong opinions, I could be wrong, it is okay to disagree because I am doing the same to you most of you. So, give and take is okay, do not worry, we are professionals, we can still share a cup of coffee tea. So, first of all meaning of test object, first of all what I realized is, so I have not met anybody else apart from me who is a tester and he is researching test engines in the world. So, if you come across somebody please introduce me because I learn passively from people's work, JUnit or TestNG, I go through this person's writings, try to find something without looking at the code okay, because I want to develop something of my own and do something better than them for the context of software testing. We do with at a higher level testing. So, first thing which I realized is that this calling something a sweet and fixtures, putting a class level fixtures in the class, a sweet level fixture in a class is an empty pattern and if you want to study technically about it, it is called composite design pattern. So, I thought of a composite test object. So, I have a test session, a test stage, a test group, a test group slot, a test module, module slot and then a function and then test. That is the eight level structure right now, it could actually increase because the moment factories of those kind of things. So, everything is composed of everything. So, everything is a test okay. So, it is not outside view that run session now and step one, it is not a data structure view, it is an object view internally in the framework. We have less time. So, I would just focus on the last layer okay, so that things are simple as well. So, in Arjuna the test expresses, it tells about itself. Now, what you should know is that for three years Arjuna was a Java library, that is how I was developing it. In Jan last year I realized I picked up the wrong programming language for what I have to express because programming is like poetry. You reach a stage where you find that this is not what I wanted to express like philosophy. So, I realized it is not the right language because unless I go into complex constructs, the test was always behaving passively. Somebody outsider was asking, are you annotated with that test? So, I chose Python because in Python it would look like an annotation, but this is actually called a Python decorator. It is a pre-processing instruction. So, the module actually talks back to the loader. I built on that concept because that is where the philosophy is that the test, so you see I told you I code philosophies. So, the philosophy of test telling itself needed the right programming language for me. So, I have switched, I rewrote everything in Python after three years. So, you could have a shy test okay, doing nothing, nothing much, but you could have a very expressive test and how simple thought process can out do somebody asked me. So, you mean to say you are working on a replacement of two decades of somebody's work, which is an open source community work. I said not my fault that after 20 years they are able to produce this. I produced what I could produce and this is what I produced. Learning some test engine, better than test engine. Test engine cannot do this, what you see right in front of you. If you do not believe just try doing data demo testing with test engine and tell me where is the multi data provider okay, in which you could have linear arguments as well as mapped arguments. You cannot have that. So, you see this is not a shy test. The test has lot of things. This is example of built-in properties. You could tag with bugs. This is a custom user property. These are built-in properties priority based filtering and all those things are tied around it. You could have runtime evars. Test NG in Java for example provides you with one kind of variables which are called parameters. Arjuna has I think five or six types of them because it separates metadata from properties, built-in properties versus user properties from evars which are execution vars versus runtime objects. You do not have to do think about thread safety because thread safety is guaranteed by Arjuna. There is no synchronized keyword in Python by the way. So, it has to that way. So, most of the test automation engineers they make mistake. They do not use for example thread local in Java. So, the moment you go for method level parallelism, the code breaks. So, I looked into those patterns. I consult on review of frameworks. I have taken a note of the most common mistakes people make in test automation world and developers need to sympathize with that. We have different needs. We do not come from a core programming background. There are different kinds of mistakes which a test coder makes versus a developer coder. There I usually see design patterns mistakes when wrong choices are made. In test code, the average code reduction in my code review is 85 percent in India, 85 percent code reduction. In a few settings, that is the kind of code which I wanted to make perfect. So, you see threads. So, you have a multi kind of threading exclude if. So, if those are few who have worked in test NG, we say depends. So, you see test NG does not even define that it is not dependency because dependency can be inclusion and exclusion. It meant exclusion, but it asks you to write depends on. If you are depending on something, you could have said that I should be run only if this succeeds. That is also relationship. So, I separated relationship. Exclude if problem in. So, you see this whole pass fail is a relationship. Am I looking for problem? Am I looking for percentage or I am looking for this? So, there are separate parts to these relationships and functions. So, that you can provide multiples of them and then of course, drive with many data sources, record for which you were writing all those curly braces and objects or records. It checks actually that you are providing only fundamental objects, data function where you can provide any function. It would dynamically call that function with the provided arguments or data class. It would construct an object of that class with the provided arguments which could be keyword arguments, normal arguments and then call it. If you do not believe me, my challenge is go and try writing a lazy data provider in test engine. Try it. Try writing a lazy data provider in test engine where the data is faced from a remote web service. I have been trying for the last three weeks because it is not that I only work in Arjuna. I do work in test engine. Three weeks I am struggling with that problem because it forces Java iterative protocol on you. It does not have a data provider protocol. Test engine does not have a data provider protocol properly. It banks on Java iteration and it has next and next that architecture does not work when you do not know how many entries are there. It works only for deterministic data, not non-deterministic data. So, this you see I hope you now know the layer at which I am talking of test. It is a foundation. The things which people are trying to fix in frameworks were supposed to be, many of them were supposed to be test engine problems. We are fixing them in the wrong layer. Alright, introspects. You see why Python? Because in Java it is called reflection. You have heard the word reflection. If you want to sum, so you see it is a thought process of the programming language. In this class, which are the methods? You are not asking from class, tell me your methods. In this class, what is the method? Which of them? It is outside an approach. In Python, everything is a self-dictionary. So, when I am a class, I know my variables and guess what? This is called introspection in Python. So, you see the philosophical conflict. This is where it matters. You can't pick a opposite philosophy language like Perl. Perl more than one way to do it. Do one line magic and then working in a context where robustness needed. You can't do those things. How many times have you written code where you wanted to check what is the current method? What is the class which contains it? What is the name of the class? What is the module of the class that goes into reflection area? How many times have you written this dot get class dot get simple name dot get name? You keep doing it. The moment you create a framework, you keep doing it. And then you have problems passing it around. And I don't know whether you paid attention to the argument which is always my. The signature always remains the same. It's not that you pass five parameters and then you use data provider and you did this signature keeps expanding and contracting. The signature in Arjuna of a test is always same. And that argument, you have to write it as my. Otherwise, it won't run. It's a static audit error in Arjuna. It forces you to use this name because that's why then it would read my.info. It's a test talking back. So you see all those decisions go at API level. My.info.session.meta. I can inquire which session I am in, my universe, which stage of the session I am in, which group I am in, which module, what is the name of the module, what is the qualified name of the module, which package contains it, what is my name, what is my qualified name, which slot, in case of dependency resolution, if you split the module into three parts, which slot number I am in. I am in. Everything. I know about everything as a test. And of course, the properties. Whatever you set here or in its parent or in its parent, everything you can access using same approach. Same approach. We are dealing with the same object. And Arjuna takes care of which of these should be read only. What you can manipulate, what you can't manipulate. All those checks are there. Fed safety, everything is there. It decides. Depends. Dependency resolution is done by the test. So I check who do I depend on and what happened to them. If there is a problem in them, I exclude myself. I surrender myself. Nobody is taking decisions for me. And this is not in your code. In the framework code, architecturally, if you look, you would find test objects taking decisions for themselves. And the children act. Of course, this is where you write and you would do whatever you wanted to do in that test. And asserts. Now, asserts, you must have heard soft assert. They said assert, you use ham crest for this type of this. What I did was, I wrote a single base of assertions. On top of that, soft assertions or normal assertions are built. The core is same. People patch ham crest on top of normal assertions. I wrote the core as ham crest style so that normal assertions can be built on top of that. There is again a slight difference. The sequence of arguments. See, you talk of usability of code. I talk of usability of API. It is a serious subject. Nobody talks about that. Why should first argument of an assertion be expected and not actual? Listen to it. Assert equals expected comma actual versus assert equals actual comma expected, which sounds intuitive to a human. And why the hell all the test engines in the world for two decades have been using the non-intuitive form? Do we talk like this? Expected is same as actual. Do we talk like that? Or do we say actual is not same as expected? The argument sequence is not intuitive. Check assertion libraries. I go to that layers. That is the area I am working on. So, that is why this is if only one person had turned up or if nobody had turned up, I could have given presentation to myself. I do not mind that. But yeah, these ideas are not being discussed. Everybody talks about some frameworks. Anyways, Pythonic simple assertions. Of course, you can use Python assertions. You could use assertions. And you see steps. Do you notice something? In no test engine in the world, steps is a built-in concept. You do not notice it. But when you are dealing with extent report, a layer report, every time you actually create two tests. One is a test engine test and one is extent test or a layer test. Because steps is not a test engine concept. Steps is not a JUnit concept. Steps is not a concept in any of the unit testing engines in any of the languages out there. I built it. One problem was being discussed by Nareesh today. What if I put try catch around assertion? Try it in Arjuna. Try it in Arjuna. I've solved that problem. I've solved that problem. Even if there's an assertion error and you put try catch, the result is captured by that time at the back end. The test would still fail. You could proceed in that test. That's okay. But when this test is reported, that particular assertion would be used to report your test as a failure. You can't play with it. Because the way Arjuna records or reports the results of a test is based on steps. Everything which happens in the body of your method is a step. Assertion is a step. Logging is a step. It works that way. Everything is being recorded at the end. The results are calculated based on the steps. So you see, you could have put try catch, but by that time, the result is already located. It's already done. So the test would still fail. You can't play with assertion. Anyway, so this is one example. And by the way, it enforces the purpose. It's not assert equals. Whether you want to give purpose or not, it's okay. Without purpose, any higher level tests, assertions are useless. Because in your reports, if it tells you one not equal to one, what was this one? What were you checking during that time? Number of entries in a shopping cart? Number of books deleted? What were you checking? I didn't make the purpose argument optional. You need to provide the business purpose because without that, in fact, unit tests, reports are also useless without the purpose argument. Because too much troubleshooting time goes into that. So to this day, I don't understand, why did they overload and provide libraries like this? Okay? And you see, I have a history of those engines to learn from and the problems which people face. So they did great, but we need to move on, especially in testing world. Don't use Arjuna. Do something like this build. At least, I would establish the need for a custom engine for us. That I'll do. You're better at coding. Go ahead, do something better. Don't use this, but do something. Because this test engine, J unit game, not for us, not in the long run. Somebody needs to solve this problem. I just open source my standard. That's it. So you see, simple assertions, fluent assertions. I was anyways working at it. So I developed the concept of soft assertions also, and new concept called lazy assertions. Because anyways, I was taking a standard. Lazy assertions are lazy at time of execution as well as evaluation. Soft assertions are lazy at, greedy at time of execution. They get executed immediately, but evaluated later. Lazy assertions at this stage actually nothing happens. In the third or fourth line, nothing happens. You're just adding which assertions you want to execute. When you say dot execute, that's when all the assertions get executed and then evaluated. It's a new concept absent in all frameworks. When do you use it? I don't know. I had anyways an architecture to support it, because it was a stage-wise process. Maybe we'll find a problem context tomorrow. Informs. Yeah, test reports itself. Test reports itself. It reports its children in case of surrender. And yes, surrendering and exclusion could be two different things. There are different status. There are seven or eight states of a test, not simply pass-fail error. If you're skipping, skipping is a different state, because skipping is different from exclusion based on dependency failure. If there is a data, some construction failure in test, that's a separate kind of a problem. And before I forget, yes, Arjuna separates issue from the failure. So when an exception happens, assertion exception, non-assertion exception, first an issue object is created. Then this step is marked as failed or erred because of that issue. Then this test is marked as failed because of this step failure. And then anything which is failing because of this test because of the dependency would now point to this particular issue ID. So you have one to many mapping. Things which you spend time on. Things which you try to solve at parsing report files, try to do all that business intelligence, ML and all those things. Believe me, many of those problems are not even worthy of ML. But you are solving them at the wrong level. They are simple test engine features. Anyway, so the test expresses itself. It should have freedom of expression. You could write the simplest test possible. Just write at test function, the most shy one and the most involved one using the same framework. Introspects, it should have access to all the information. It decides for itself, takes decision surrender, go along. This could be extended to other things. Acts, asserts, informs. And something which I'm not, yeah, before I forget, yeah, I run a company called Test Mile. I am the CTO at Verity. I'm a consulting CTO for Verity. I am consultant for Mooliah. And I'm the community connect for Step-in Forum. The slide deck would be anyways available. So you can sort of take details from here, stay connected. One final thing which was not there in the original presentation. On that note, I'll conclude so that I can open it to questions. Let me show you something which people want, but which never built. And even if they build, they build it at frame of affairs. So you see, people want these kind of things. I want to run all tests written by Rahul. I want to run priority one, two tests on the relationships. They want a grammar, but they were trying to create that grammar at framework level and half cooked. I created that grammar for you in the engine itself. So author is none. It is not defined or rating. You see, user properties. These are dynamic properties, runtime. Based on that, you can do selection. How do you do that in test engine? When everything is just name-based and name is an external thing. So you see, you ask me, I'll find what is my rating and what is your filtering rating. And if it doesn't match, if I don't meet the criteria, I'll surrender. Let me be as a test and that's the power to achieve this in the other architectures, very complex job. Try it. So unstable, long running. You could have these flags, choose based on that. And of course, evars. These are those evars, runtime things you could have set. You could choose based on that. You could actually tag-based. These are things which people solve in commercial tools. Tag Chrome is defined or multiple tags or even bugs. Regression test. I want to run tests which were, I had marked earlier with this bug idea. I want to run them. And yeah, there are 13 or 12 layers of fixtures, not four, like in test engine. So you have very precise control on setup and tear down. So just explore it, get in touch. I can talk about original specific, but the purpose of this presentation, the core purpose was to introduce, there is more to test automation than talking of Selenium Appium. It's a much, much more deeper field if you care for it, if you want to explore. I take huge pleasure in talking in these there. On this note, I'll conclude. Thank you so much for your patience. So we have time for questions. Yeah, please. That logic, you'll have to create them. So it's just like test engine suite file. The only difference is that test engine doesn't let you decouple suite from groups. So if you are repeating same group, you are forced to write same XMLs over and over again, right? Similar instructions with different variables. You can create a runtime for that, you'll write some kind of wrapper tool around that, right? So once you've done that, this is the file which you created. Once you're done with that, you just need to pass. What is the group name? You can pass what is the group name and just run it. Let me just try to find it. I was running a lot of examples yesterday, so that I'm not stuck in this. So you see, it's a command oriented interface, run group, run names. So you can choose which module to run, which function to run, run the full project, run a particular session which is equivalent of suite, run a particular group directly. So decouples groups definition from suite definition. And in a session, you can, if I show you more complete example of equivalent of suite file, you can, these are named session files, okay? So if I show you complete thing, this could actually start looking like this, okay? You have pictures in its session and session which you can place anywhere. You're not forced to put it in class like in test and G. That's a wrong place to put a before suite. It's a very wrong place. It confuses a lot of people. So you place it anywhere, actually. Dynamically, I'll call it. And in it each stage, stages are sequential just the way testers want, right? Sanity, this, this stages are always sequential. Rest everything is parallel. Groups can be parallel. Modules can be parallel. Function test, everything can be parallel. But stages are, and then again, you have multiple fixtures. And here you, in each stage, you could give multiple groups. So you just refer by name. And what are the variables which you want to pass? That evars thing which you saw in annotation or decorator, those evars you can pass here also. Finally, it clubs all those evars in the context of all the object hierarchy. And test can inquire back at one time. So that would be a stage to stage dependency, a feature I'm going to build. So there's a function to function dependency built. Module to module dependency built. So there would be a group to group and stage to stage. So there would be four types of dependency management. So by default, it doesn't do that. Or maybe the other way around. I don't know when I construct that feature, I'll know. But the idea is that if, let's say your sanity tests are not passing, why should the next be executed at all? So no run time status checking built into the component. Anything else? So is this tool compatible with tools like night watch or I don't know about those tools, maybe you can discuss. See any integration problem, if you look at is an interface problem. It could have a rest interface, a network interface, GRPC or a command line. It's more of an integration thing. So I haven't even thought of, I don't know about these tools. But then can they be integrated? Of course it can be integrated. Yeah please. Cucumber was never meant for the tests which it is being subjected to in the industry. Cucumber uses Gherkin and Gherkin was supposed to write only user story tests. Today I get inquiries. We have 10,000 tests. Can we convert them to Cucumber? And companies like by the way, who's created Jira? They are doing that. A company specializing in creating an agile tool is using Cucumber for all their tests. That's an anti-pattern. Yeah, that's a very bad measure. Very bad measure. We can debate around that. But you see that given when then syntax, it is good for user story, higher level tests. You have deeper tests than that. The moment you try that to push into the way KDT, keyword driven testing people tried. That let's just write keywords and just run the test. I have literally seen C sharp code in Excel sheets. You see, there is a point where a certain way of doing things gives up. It's a code smell. It's talking back to you. Listen to it and change your way. There's nothing wrong with Cucumber or Gherkin approach. But use the right tool for the right type of tests. That's what I'm saying. Okay, try Cucumber for fuzzing. Search about fuzzing where you might be executing 1 million tests and try it out. Try writing a performance test or I could actually give you a lot many examples. If version of a test in your mind is UI testing, Cucumber could be a winner. The moment you start doing deeper tests, multifaceted tests, it's a problem. And multithreading is a known problem by the way in Cucumber. We have run out of time. I'm happy that these disagreements are being generated because I created Arjuna out of disagreements with the way people were doing stuff. So I'll be outside and I'll be available maybe throughout the evening to have any discussion on this. I hope it was not a waste of your time. Thank you for paying attention. Let's do it.