 Thanks for coming to the session right after the lunch. I know must be sleepy but please try to be awake. So, I am Amita Sharma. I work for Redhead who passed 5 to 6 years now and senior quality insurance engineer there. And I qualify a product called Redhead Directly Services which is essentially an LAP server and it is a very important component of free IPA or identity management server. And it is being used to support many other products as well. So, being a tester I will talk about little about my test framework which we are using currently and then the framework on which we are trying to migrate. I will give the examples of my product. So, I will give a brief introduction about that also and at the end we will talk about the migration process. So, this is a little introduction about my project which I work. 389 is the product which is open source product and in downstream we maintain it as Redhead Directly Services and we qualify this product to make sure that the product is bug free and it should be feature rich product. So, there are some beautiful features over here. Replication, you can configure replication between the many Directly servers installed on different posts as well. Your one server can be in India another can be somewhere else geographically that does not make any difference. So, replication you can configure like databases will be same and it is done for the load balancing as well as failover. Faster policies you can configure and when sync we provide the synchronization between Active Directory that is Windows Directly Server and 389 as well. So, you can basically sync the users and entries, configuration, etc. from the Windows AD server to 389. ADDLY server is it is a Java console from which basically you can manage your users and configuration for the Directly services. So, we have been using a bash-based test framework which is known as TET. It is a very old frame test framework and basically it was based on bash. So, it was bulky, non-skillable and some of the reasons the main reason was it was missing multi host support. So, if I want to test my server as a multi master application I have to do it on a single host. I have to deploy all the server in the single host. I cannot test it on different host. So, that is the problem we were facing in this test framework. So, we have chosen PyTest as a test framework because it is Python based. It is the code base is highly scalable in PyTest. It supports old test framework as well migration is easier as well as it has many APIs which supports many functions internally and specially for our product it supports multi-host testing. So, that is why we have chosen PyTest. Now, a little introduction about the PyTest framework. Installation is very easy just one command you need to do PIP install PyTest and you get the environment of PyTest to use it and then directory organization is very crisp you need to decide on how you want to structure your test. So, this is my structure of the directories how I have created it. So, it will have all the features automated under it and tickets will have all the bug verification testing automated under it. So, this is the directory organization we have done. Naming convention PyTest comes with its own naming conventions you have for example you have to have a prefix as TechTest for all the test cases functions so that it can pick up all the functions and execute them. There are ample of command line options and as I said it is a very feature rich framework it provides you with fixtures and markers and test classes which you can use during building your framework and automation. Let's start with the fixtures I'll give you the example as well. So, what are the fixtures? Fixtures are general functions but there is an annotation to mark them as fixtures. So, these functions but generally they provide they provide the platform to execute your test. For example, I want to test my setup of multi master application say I want four masters four directly servers and I need the configuration of the replication. Generally this kind of configuration takes the whole day to get set it up and executing your test cases might be matter of just half an hour but configuring and setting up the setup itself takes a longer time so that so to get rid of such kind of lengthy process what you do you automate it and you put it in the fixture library fixture function. So, whenever you execute your test cases in that module what it will do it will do the setup for you in the fixture function and it will execute all the test cases at the end of the execution of the test cases when you are done it will tear down them. So, that is what the basic functionality is. Now, we can take an example a toy example how we define a fixture and how we use the fixture. So, here first of all you import the by test statement you need to write and then this fun function I have marked it as a fixture function annotation by this dot fixture. So, this is how you define a fixture function. Now when you call this a function f u n within a test function like this I have called two fixtures over here. So, it will use that function fun and it will use function one as a fixture it will execute both the functions and then it will execute this test. Similarly, I have called fun function here. So, it will execute first function and then it will execute this test test case here. So, there are different ways to define it and to call it as well. For example I have not mentioned the scope of the fixture. If what if I do say I will do this thing scope is equal to module. So, what does it mean it means that the scope of this fixture function is module it means it will be executed for all the test cases just once. It won't be get executed for both of the test cases it will be executed just once not twice. And if I omit this it means the scope is function. So, it means it will be executed for all the test cases you have mentioned over here. We can see the demonstration also. See now the code which was under the fiction function is being executed for all the test cases. And it also demonstrate pass and fail and give you a nice report which is very mandatory for your troubleshooting. Like which test cases failing and why it is failing. This way you can check that. Not just the scope we can mention here auto use is equal to truth which is a flag if you set this flag as true it means that this fixture function will be executed by for all the test cases you have mentioned in your module. You don't need to call it even here. You don't need to call it even here and even here. It will be executed for both the test cases automatically. Now you must have seen that here I have used a marker used fixtures and in the another test case I have used the name of the function. So, these are the two different methods to call your fixture in your test case. You can use the marker function if you want to use more than one fixture or you can mention the name of the fixture function within the brackets. So, it will execute that fixture for that particular test case. So, this was about the setup. I will also show you an example of tiered off So, generally tiered off function what it does is whatever setup you have done for your test cases to be executed, tiered off essentially tier that out means that setup will go will be like if you have installed some packages or you have configured your directly server on your machine. It will remove all those packages and it will remove that setup from your machine and it will give you the clean machine back. So, in this case you have to have a request object in your fixture function within the parenthesis and then you have to define a fin function finalizer. This is the finalizer. You can put any name you can change it to final or any fancy name whatever you want but this is mandatory. This will go as a request.ed finalizer and within the function name which is executing your tier down code. Whatever you want to do in the tier down function you need to put it in the final function and that is how you are calling it and returning your setup. This X is essentially your setup or the configuration you are doing in your fixture function. So, let's execute this code and see what it does. I have changed the name but I have not changed the whole code function so that is why it is giving the error. So, you have seen even if this line of code was in the fixture function but it has not been executed before the test. So, test case has been executed first after the setup and the tier down has been executed once the test cases have been completed. So, what PyTest has done recently it has introduced a yield keyword or yield function which by using which you can again cut down on the lines of code. You do not need in your fixture function. So, you can omit this request object. You can get rid of this final function. You can get rid of this request at finalizer. You just need to do is use a yield keyword over here and then instead of return you say yield X and then your code of tier down. So, all these lines are now squeezed into one line of code. So, even less boiler point. So, if you execute it it will be same as the last. So, you have seen how PyTest has squeezed your code of 5, 6 lines into one line. So, that is how we call it less boiler point. So, multiple fixtures what does that mean that I have shown you. You can use more than one fixture function in your test test module. Fun 1, Fun 2, Fun 3 number of functions you can declare as a fixture function. And fixtures using other fixtures which is called the modularity. Sorry about the question regarding the yield. So, basically the test cases will be, you would generate an iterator of test cases and then the yield basically turns like the original. But then you put the tier down after the yield statement. After the yield statement you put the tier down after the yield statement. Yeah. So, yield is basically replace the return statement. Right, but that is all because it is an iterator. Yes. So, what you essentially do not need to explicitly iterate from the test cases because whenever you put a test keyword in your functions which you are executing that will be treated as a test case in the PyTest. If you are running it PyTest hyphen s, hyphen b and your module name whatever command like every line options you are giving and your module name. What it will do it will pick up those functions which are marked by the test keyword prefix and execute one by one all those functions and return the pass and failure. Okay. So, within that you can call the functions as fixtures or you can use markers and like that. Test classes also you can use that. Okay. So, your fixture function can call another fixture function also within it. So, that is called the modularity in PyTest. Returning values and object we have seen that you can use the return statement or you can use the yield statement. Yield is better than return because it has less boilerplate code but as it is just released. So, many people are not used to of it and it doesn't give the more clarity of the code as of now. Okay. Now, markers. You can mark your test functions according to which test case you want to execute. Sometimes there is a troubleshooting in troubleshooting process. We don't want to execute 10 or 15 test cases which all are there in your module. You just want to execute one test case which is related to your bug or related to one feature. So, you can mark that function with a marker PyTest.mark .the keyword. So, I will show you example here. Okay. So, I have marked this function with the keyword testmeet. Now, here I will pass. See. It has not executed all the test cases. It just has executed test case one which has been marked by the keyword testmeet. And if you comment it out obviously it's going to execute all the test cases. Remove this mark. It has executed all the test cases. Okay. So, if you want to for example, if you have a bug related to a particular feature or related to a particular release so you can mark those test cases of that release related to that release and just execute in one. You don't need to pick one go through the lengthy report of result which contains all the your test case execution first. Okay. So, this is not maybe some people think that no, I don't want to mark the test functions even that is the lengthy process. So, what you can do, you can use a node ID. What essentially is the node ID? Okay. So, this is your file name. This is your test class and this is your function name. So, this is essentially the address of your test case which you want to execute. So, just put the module name column, your test class column, the test case you want to execute. It will execute that particular test. So, this is that much flexible. Some people will say, okay I don't even want to do that. I want to use what is existing over there. So, you can introduce your name or whatever keyword in any test I will say this. Okay. And I will ask it this one to execute the test case which has this keyword in it. So, it has executed that test case which has this particular keyword in it. Even K you use with the expression which you have introduced in your test case which you want to execute. So, under this test case I have this test where I have written my name in between so I have used that expression to execute this particular test case. Is it possible to use the contract because I can't see them doing very well. Maybe we can switch off the light. It's a project. Is it possible to switch colors on black or white? You can go to five preferences. Here, preferences. Think of the profiles. Just put the mouse on it. You can use a different example of color. Better? Yeah, a lot better. So, here I introduced a keyword in the test case which I want to execute. Now, I have executed with hyphen K command line option and put that keyword here. It has executed only that test case which has this keyword. What you can do you can introduce this particular keyword in any of the test. Now, it will do. Tell me. Perfect. So, you have seen you can use the keyword with the hyphen M you can use it. You can use the node ID or you can introduce an expression which you can use with hyphen K. If you want to the whole thing or whole class, one class maybe in one module you can mark that particular class with a marker and can use with hyphen M function. It will execute all the functions which are there in your test class. There are other this thing available markers. You can list all of them here. So, skip it means if you put that marker above some test case with a condition that maybe for real life example you don't want to execute some particular test on some platform. I don't want to execute this test case on Windows because it's Linux compatible. I don't want to execute this on Ubuntu. So, because we test on different operating systems, right? So, you can put that condition there. Skip if your operating system is Windows then skip that test. X, fail, condition and reason. So, this particular marker is used if you want to explicitly mark your test case as fail with the condition and the reason. Parameterized you can make your marker your function as parameterized function where you specify the arguments argument values. And use fixtures I have already demonstrated the example of the use fixtures. You can put the name of the fixtures and your test case will execute all the fixtures which you have mentioned in this particular marker. Similarly, try first try last not that just that if you want to develop your own markers you can write them in the functions and you can put them in the config file and they will appear in this list as well and you can use them in your functions. Why is it try first and try last? What is that? What is that try first and try last? Okay. So, this marker is try first means that particular test case will be executed first and try last will be executed at last. Okay. Any questions related to markers and fixtures or pitest in general? Okay. So, this is probably the end of the talk the migration process which we are following for our product is first of all you need to get rid of all the old test cases because over the period of time where the product is getting mature maybe 10 years, 15 years there are the test cases of time somewhere in your library which are not relevant to your product anymore because there are some new features that are getting introduced in the product and many bugs have been fixed over the period of time so there are the test cases which are not even valid for your product so just get rid of those test cases no need to be make your test framework so bulky if you say I am doing the testing of this product with a 10,000 test cases it doesn't mean you are qualifying that product correctly maybe your 50% of the test cases are not even relevant and valid anymore so just go through that and this should be a phase time like after one year I have to go through my test cases which are there in my test framework are they relevant or not so there should be some timelines they are fixed by which you should go and verify it then make a one-on-one mapping between your test cases out there and the test cases there are some of the testers which are a little lazy to add or edit the test plan for adding a new test case they just automated but they don't edit the test plan which is there so just make sure that there should be a one-on-one mapping between your test plans and the test cases within the automation so that somebody comes in and can relate that mapping and can read out about the test case which actually does which bug verification it is testing or which particular feature it is testing divide the test cases into the phases if you are migrating your test framework then divide it into the phases so we have done it in this way like for 389 we have focused in the phase one to the features which are more important to the customer or the users for example application is a hot feature your win sync is a hot feature fractional replication is the hot feature so all those features which actually affect the customers and the user move them first and then slowly go by phases then make use of the doc strings to entitle your test cases doc strings are not only important for others to understand but you are writing in your automation but lately you can also use them there are some scripts available with which or plugins with which you can pull those doc strings and put them in your test case management system where it can be used as the test plan so you don't need to write your test plan or edit it just as the doc string run that plugin it will pull that doc string as a test case into your test plan bugs and features like I have shown you initially that I have structured my phytest framework in such a way that my bug verification automation code will go under the tickets and the features will go under suites so you try to bifogate or try to come up with such a directory structure under your test framework so that it doesn't look messy and don't confuse you and the people as well so that's it for these are the links which is related to my product and phytest I have referred when do you migrate the test what do you use before that we use those tests and now we consider to migrate to phytest any suggestions how to I know one of the member of your testing team Sachin Ghai I know one of the member of your testing team it's under ogie right ogie Michelle ogie ogie you work for ogie so your testing team is we don't have testing team we use we welcome VDSM which we treat in python it's a power button that we install on the host and currently we have bunch of unit tests very scrambled around so phytest actually support it support nodes so you just so if you don't have time to really migrate all the test cases which are written in the nodes you can start from now you can automate the tests which you need to automate right now in phytest and slowly you can go because it gonna execute with the phytest also the existing one so that is the process you can pull how can you at the time for each of the test to see how much it takes it to one there is an option to generate a full length report in the phytest so you can do that more like an option sorry I have a question regarding the fixtures is it possible to extract to use external dataset like an xpl server and actually somehow get that into a fixture get that into into a fixture actually it uses actually I am not born through that because of the time so there is there is options of params so you can put the parameters in it I trade through those for example I have m1 m2 m3 3 servers okay so you can iterate from whatever test cases you have written that test case will iterate one by one through the fixture for all those parameters you have mentioned in the open okay and then you can so how will you get dataset from xpl server that's how maybe you can put that in the parameter your location wherever your databases divide them in chunks so it will iterate with all those anyone else so I would like to thank this guy to pull some initial audience in and then we have a great number at the end thank you very much for listening