all right so in the previous class we have started implementation of framework so as part of that we have created a folder structure and then we have taken one test case on this station and we have done some basic stuff and we have created some page object classes and test case and we have executed and now today we'll go on to the next one next step adding logs to the test case so first of all we'll understand what is log and how many types of logs we can generate and what is an advantage of generating the log messages so we'll understand some basic stuff from the logs and then we will see how we can generate the logs so basically what is the logging means so we can record all the events in the form of text which is called a simple logging process recording all the events in the form of text so what does it mean so suppose whenever uh you are executing your test cases right so your test case is doing some event suppose it is launching your application it is logging and registration so it is performing some actions on the application or some events so we can log all of those events in the text file in the form of text and which is called as a logging process and what is an advantage of getting the augment oh what is the advantage of generating the law so normally there are two kinds of logs application logs and automation logs so application logs means what when i uh any user is performing some actions on the application back in the back end side the log files will be generated so whatever actions are done by the user or customer on the application every event will be logged into the log file in the back end side but as a user we cannot see what exactly locking it is but it will internally logging each and everything so the main advantage of using log file is suppose in the real-time applications in the production any user is doing some unauthorized activity right so in that particular case they can easily track the information and they can also do the immediate action or they can take necessary steps whichever is required so they can block the account or they can hold that account something like this so the basically log file will be used to track the information like whichever user is doing whichever event or whichever action on the application they can track everything into the log file so they will maintain the log files at the back end and they they can they can generate every time every second the log files will be generated and there are specific a team they can analyze the log file they can monitor the log and it is also a kind of a security mechanism which is provided to the application okay that is called log file and when you come to the automation so our automation project also we will maintain the log file so because we can also log all the event from the application through the test case whatever actions we are doing on the application so every action we can log into the log file but what is a benefit of log file in automation is suppose tomorrow if any test case is got failed that information is also part of the log file so sometimes the developer will ask to provide the log file because only depending on the ui and the steps you provided to the developer they cannot analyze the defects sometimes the defects will uh reproducible in queue environment but the same defects may not be reproduced in the dev environment in those cases developer will ask you to provide the log file so along with the defect information like test case steps bug then screenshots you will provide everything right similarly you will also provide the log file and developer can understand the log file and analyze the issue and accordingly they can fix the bug so that is the main advantage of using log files so in automation also we can create our own log files okay now these logs are different levels they are different levels of log levels what are the different log levels so all trees debug logs info logs warning logs error logs portal logs so these are the different locks three four five six types of logs okay these are the six types of logs which you have so trace debug logs info logs warning error button okay so this all and off these are the options we can set in the log4j.xml configuration file so that leave for now so the main six step six types of logs are so trace debug info these are called log levels okay suppose uh if you set log level as a trace then you will get all types of logs trace debug info one error for all types of log you will get suppose if you set log level is a debug then you will get all the levels from the debug to lower levels okay and suppose if you set log level is info then you will get info logs along with warning error photo so lower level logs also you will get along with info similarly if you set log level is equal to one then you will get one error part and if you set log level is equal to half then you will not get any log messages and if you get log if you set log level equal to all then you will get all types of logs so these are the options which we can set in the log file so in the log configuration file so whichever log level you set from that particular level all lower level logs will be generated in the log these are called log levels okay so we understood what is login what are the log levels and where we have to set this log. So there are two things we need to understand on the log. Appenders and loggers. Appenders means what and loggers means what.
These are the terminologies we need to understand. Appender is nothing but. Appenders describes where exactly we want to generate the log file.
So we can generate the log file. We can generate the logs in the form of file or we can generate the log messages inside the console so when i run the test you will see some message in the console window right so we can generate the logs log messages inside the console window or we can create a separate file and all the logs messages will be created inside the file but which one we will prefer we always prefer the file why because if you create a log messages inside the file it is easily download and we can easily share the file to the developer and this is available permanently but when we generate the logs messages in the console window and these logs are available only at the run time and we need to as soon as you run the test we need to copy all the logs manually from the console window then again we have to paste it in the file and then we have to share it to the developer this is a lengthy process and these logs will not be available permanent if you run the test case one more time the old logs will be removed so this is not preferable where you want to generate the logs always we generate the logs in the file itself so who will decide that where you want to generate the logs either console or file appenders there is something called appenders and these appenders will decide where to generate the logs now something we have called loggers and what is the logger means the loggers will decide what type of logs we have to generate like in which level of logs we have to generate that is decided by the loggers so this is a basic understanding which we need to have so now let us look at how we can generate the logs for our automation so to generate the logs for our automation only three steps one is we need to have one configuration file log for j2.xml this is the main important file in this file we have to specify appenders and the loggers okay that file contains the appenders and loggers so where you want to generate the generate the log files and what level of logs we want to generate so that information you can specify inside the log4j2.xml file this is a configuration file okay and accordingly we have to update base class and account registration test we need to add log messages because the same log messages will be logged into the log now let me show you step by step so if i go to their official website what is this log4j just type apache log4j2 you So this is their official website Apache log for J2. And this is also a third party library which is developed by Apache Foundation just like Apache.
poi we have right for excel file so similarly this is also developed from apache so if i go back here they will provide all the information how to there are a lot of content is there even developers also will use the same concept for generating the application so here the main important thing is we need to add a dependency in the palm red xml file so by default you won't get this you need to add required dependencies in the palm red xml so if you go back to the palm.xml we already added two dependencies for log4j if i look at here yeah these are the two dependencies which we had it and this is additional dependency sometimes if there is any jar is missing we will add this otherwise no need okay so this is log4j core and log4j iphone api so these are the two dependencies which we need to add so let us see what is the current version of this log for j i go back and see a1 repository and okay so there are multiple versions are there you can see alpha beta beta one so always you can try a stable version 223 one so we have a little bit old one so let us make this 223 one you can also take this alpha version but beta testing don't try this is still in a testing phase alpha version uh okay sorry beta version you can take but alpha version is still under testing but we will take this one 2.23.1 which is a stable version okay just try to update the version number that is enough so 223 1 223 1 and here this is also same number so 223 1 this is the latest version i'm keeping here and 223 1 okay okay yeah both we need so log for core is required api is also required this is optional you so sometimes we'll get some exception uh then we'll add this okay so anyway i'll share this palm read xml you can get it from there okay so i'll add this here in the chat box you can get okay so once you added these dependencies we will get a log for j2 dependencies so library is ready and once you've done so you can just try to update the project once go to may 1 then update okay so once it is done now the next step is we need a configuration file which is most important so log for j2.xml will control the everything appenders loggers everything we have to configure only in the log for j2.xml and this butler file this is a resource file so we need to keep that file under src test resources you so this is the under this only here we have to keep nowhere else src test resources so from where we will get log for j2.xm if you think if you go back to their official website okay you can find somewhere here or else uh you can directly type as a log for j2.xml so if you just type it here it will directly go to log4j2 xml file so they will give a sample templates but these templates are not exactly accurate to your automation projects we need to do some customization okay so some people will use xml file log4j2.xml some people will use log4j2.property file also we can use but most of the time we prefer xml file okay so they provided some sample xml files templates in their website we need to configure according to our project. So I have already configured one file, configuration file. So I will share that file.
You can use it in your automation. So I will place that particular file inside the SRC test resources. So let me get that particular file. So log for j2.xml. The file name should not be changed.
The file name itself log for j2.xml. because this xml file will be loaded by log4j so log4j will remember the file only with this name so we should not change so let's open this xml file so log for j to xml file this is a xml file log for j to xml file so let us try to understand something from this butler file so we no need to create everything new which is because this is just like a template but we need to do we need to know few things from this xml file so mainly appenders and loggers as i told before appenders means what it will decide where we have to generate the log where we can generate the log files either console or file this is decided by the appenders and loggers will decide what type of logs we can generate okay and these two we can configure in the log for j2.xml file so let us go what exactly it is so we can see two main sections here from here to here this is called appender section this is the loggers section so appenders tag is started here ending is here loggers started here ending it is here okay so this is a two these are two parts appenders and the loggers now what i said appenders are decided where we can generate the logs right so if i go back here in the appenders there are again two more entries this is for console this is for rolling file so this is for console this is for rolling file and both entries must be there but in loggers we have to specify okay so in the loggers we have to specify the which level of log we have to generate and appender reference we have to specify so in appender there are two references are there one is console other one is rolling file now in the appender reference we have to specify file or console so when you say file here so then this appender reference will use this rolling file or when you say console here then this appender reference will use the console option okay by using this option it will decide where you want to generate the logs from the appenders so appenders will decide where we have to generate the logs and loggers will decide what level of logs we want to and in appenders we have a console and rolling file and which one we have to choose that you can specify in the loggers section in the logger section appender reference tag is there here we can specify the reference file or console and if you want to generate in a both console and file then you can enable this statement append reference reference equal to console then append a reference reference equal to file so both entries you can specify and which level of logs you can generate that you can specify in the level here so here i mentioned all the levels where you can specify all or you can specify trace or you can specify debug info warn error so whichever level of logs you want to generate you can specify the log level here okay and where the log file will be generated so if it is a console we know in the console box all the logs will be generated but where file will be created so here we specify the path so earlier we already created one folder called logs inside the project right so the same path is referred here you can see in the property section name equal to base path dot slash logs means what dot slash is representing in the current project directory inside this logs folder so in the logs folder it will generate the locks and same path same base path we are referring here also file name equal to base path slash actually here it is a variable declaration and here we are using according to the xm so here we are specifying the base path and that base path slash the file name of file is automation log file is name is automation dot log okay because the file should have some name right so automation dot log and this log file we will generate with the timestamp because every time it will generate uh same all the entries will be logged in the one single log file okay but if the log file size is got exceeded it will maintain the old log file and it will automatically create a new log file so for that reason we have to create a timestamp also so this is a timestamp dot lock so base path automation hyphen with the timestamp and this is a format time format dot log so this is the file name okay this is the format as i said is a template which is provided by apache poi and if you have not understood this you don't need to worry at all so you need to just understand only this part logger's part so you can specify the level of log and you want to you can decide whether you want to generate logs in console or files most of the file most of the times we generate logs only in the file so we can keep the file here and here most of the times we generate the info logs only okay suppose if your test case is failing uh like there are some underlying issues if we are not able to figure out them then sometimes developer will ask debug logs in that case you can put this as a debug and then you can execute so the debug is log level which will capture all the transaction between the application and your back-end system all throughout the network whatever requests are sending to the server everything will be captured from the debug So in the debug level log we cannot understand most of the times. So developers can understand.
But info logs we can understand because whatever messages we write in the test cases the same messages will be displayed in the log file. So info logs default by default you can put info and if any time developer is asked for debug log then you can put this as debug and run your test cases. Then it will generate the debug log. So this is a process.
Yes, so the base path is basically a variable. Okay, so there we specify dot slash logs dot slash is a current location and logs is a folder name which we have specified. So the log files will be generated inside the logs folder.
Okay, so which type of loggers level generate? So by default, we will generate info. So when I say info, it will automatically capture one error portal messages.
And trace and debug is very very detailed level of logs. Means what they will also capture the transactions between client and server. In between whatever transportation is happening all the client request will be captured that is very very detailed log.
So that we cannot understand that log first of all. Only developers can understand they can analyze the log. And when I put info so.
these logs we can easily understand because these are the log messages we write our own in our test cases okay so by default it will be file and if developer asks then you can put a debug log and they can execute okay so this is a template file so you don't need to do any changes in this just try to blindly use this file as it is in your automation just keep this file as it is in your automation and you can use it this is a just a template configuration file as a separate the configuration file this template also provided by apache py log for j2 so accordingly we use the same kind of a template so the main part is this one loggers inside this we can specify log level and appender reference appender reference can be file or appender reference can be console or we can specify both but console logs not useful much but file logs we have to always generate so this is the basic understanding of log for j2.xml file this is a configuration file so this base path is not a keyword actually you can put anything you can put any name but the same name we have to refer here and here okay the same variable name we can specify here and here so in xml if you want to create any variable we use something called property tag this is all xml related language okay so you don't need to understand all these things but simply we can understand this part if you still want to change this name you can change all right so this is all about xml file so apache website i have not directly copied after copying i have done my own customization So you cannot find exact file in the Apache POI website. So they provided them some some files you can see here. So this is a pender section, this is a logger section.
And here demo provided a pender reference. So this is simple one configuration file, almost to say maybe 90% of the file is same, but I have done some more modifications, few modifications, just file name path and so on. otherwise almost everything is same so this is the one i guess i copied okay so i will provide this template anyway you can use this in your future projects also wherever you want to work with log for j2 you can use this template okay so this particular log file will have only your automation logs and application logs will be captured only in the debug mode so when you enable the debug mode which will by default capture all the applications either trace or debug all so these three levels will capture all application logs along with the automation logs and when you put info one info or warner error so these logs will capture only applic only your automation okay all right so now this is a template so which we have to use i will share this template you can use it for your all your automation project same template it is very suitable for our automation testing all right so now first step we have put this log for j.xml file under src test resources now we need to just update our base class because we just keeping the xml file will not create a log fetch So we have to write some piece of code which will generate the log file.
Okay, we need to do some configuration. So how we can update the base class. So let's go to the base class.
Why base class? Why we need to update the base class? Because the base class we need to write piece of code which will load our log for j2.xml file.
We just kept the file here. But no one is using this file as of now, right? We need to write some piece of code that will load the xml file first.
that will read the configuration from the xml file so where we have to write that code in the base class itself why it is a base class because this is a common class which is required for every test case so we want to generate the log for all the test cases or not yes for every test case we need a logs so that is a common activity generation of logs is a common activity so the configuration step should be part of the setup method okay base class setup method because this is a reusable class okay so let me try to update the base class under the setup just so setup method in the setup method we have to load the base class okay so how to load this base class so how to load this log for j2.xml file inside the base class so we need a variable here logger there is a predefined classes uh because we already added apache logger logger dependencies we will get the special classes the first thing is we need to create one variable public logger object. So logger we need to import from proper package. So there are so many packages you can see here.
You need to import the right package. So this should be imported from org.apache.logging.log4j.core. This is a package.
Okay so just import this. and you can see this this is the package i'll put separately so that you can understand so this is the package so this logger class we have to import from this apache dot logging dot log4j dot core dot logger so let me see is there any other package okay sorry uh not this this is a one for logger okay i think everything is same all right so let's keep this package for not so for the first thing so this is the new package we have to import it for logger so this is the step we need to add for log purchase this is for log purchase step now in the base class in the setup method we have to use this variable logger so before creating the driver here i'll add some piece of code logger equal to there is a predefined class called log manager so from the log manager we have a method called get logger and in this we have to specify the class name so from which class we want to generate the logs right so but here uh there is no specific class name here because we can run multiple classes right so at the run time dynamically it should take the class name whichever test case class we are running that class name it should take it dynamically So, here we dynamically get the class name by using this keyword because this is always representing the class. So this dot getClass, this is the method. So this particular method will get the class name and for that particular class, it will get the logger and store it into the variable.
So this variable we have to use to generate the logs for every test case. So put the same equation. So this also we need to.
type logger to logger just a second I think one second yes I think this is not the right one to import So, these are the two packages guys remember, so by mistake if import any other package it won't work. Remember this or else just copy paste from here. So log for J. This is also for log for J import.
So these are those two special imports we required for log for J. Because there are so many classes are there so many packages so you will be confused at the time of importing so you need to carefully do it. So logger equal to log manager dot get logger. and here we specify the class dynamically we are getting the name okay so this one so don't do anything now just listen okay i don't write anything in the chart box so i think you are doing parallelly so don't do that so listen first so we pass the class here and log manage this is the statement which we have to use to load the log for j2.xml file so this will automatically get the log file j2 xml file because it will also always fetch in the resources folder there's a default path which is already configured in the log for j2 xm so log for j2 xml file will automatically get it into the variable okay so log manager dot get logger this dot get class and this logger may variable we have to use to generate the logs so whatever the logs you want to generate the log file you need to decide so this is the log project configuration done so now third step is we need to Go to the test case and we need to add all our log statements.
So whichever log statements we want to add, you can just simply add. So directly go to the test case. It's the last class we already created. Go to the test case.
Now, if I look at this base class, we already created this logger variable, right? So we can refer this variable and generate the logs. So how to generate the logs?
So each and every event, we can log into the test case. Every event. we can log into the test case okay so let me modify few things here so for example here i'm starting my test right so here i will log one message to the log file how can you log by using logger variable can we access logger variable yes right because from the base class we are getting right yeah logger dot info so in the logger you can find multiple methods you can see here you can find info method you can find a debug method you can find trace okay how many log levels we have those many type of methods we have here so we already discussed some log levels right so debug trace info warning error for tell so for these levels the different methods are there so those methods we can access from the logger so for example here i just want to log a information message then i can say logger.info logger.info so here i can pass some string let's say i'm starting starting so what is the test case id this is the test case so starting test case because this message will be displayed in the log file okay this is by seeing the message we will understand this test case is started okay and same message we can repeat everywhere suppose uh for example here i'm launching my home page and clicking on my account and then clicking on the register right so you can write another message here logger.info and here you can write some other message so i can just remove here so whatever message you want you can write so normally we will write a comment right so all those comments we can include here so here we clicked on my account link so same thing after clicking on register write one more message clicked on register link and after that so here we are providing all the information right so here you can pass one more here you can pass one more logger message so that we can say providing customer details providing customer details and after providing all the details and here we are doing the validation okay so here we are doing the validation so here you can put one more logger message logger.info validating expected message this is another log okay you can put whichever format you want to write you can write that as a simple message okay so it should be more easily understand everyone so simple language and whatever you want to put again okay for example if assertion is got failed then i want to log error message in the error message in the log file right so then what you can do is you can put this so whole thing suppose in this is whole test case right so in this test case suppose if any step is got failed because of element not visible or because of message or whatever somehow if the test is got failed you will get an exception right so what you will do put everything in the try catch so from here everything you keep inside the try catch block and from here to here everything because tomorrow if any exception comes in any steps it will automatically handle so here you will write a catch catch and whatever type of exception commonly will get an exception and in the exception block i will write a error okay suppose if there is any failure happened in this we need to log error log not info right we here we write in only info logs But if something is got failed, catch block will handle catch block will execute here we need to write an error log.
Okay, so what we can do here is we can simply say logger dot error, we need to take error logger dot error. And inside this we can pass a message what is a message test failed. Okay, and if the test is got failed, and if you want to log debug debug level logs we require so that only by specifying the debug option in xml is not enough okay if you specify debug here that itself is not enough in our test case also we need to write a debug message log i can say logger dot one error message i'm logging and one debug message also i'm logging so test failed and here i'm writing debug log It will capture all the debug level logs.
And if the catch block is executed means what our test is got failed. So also I'm writing one assertion assert dot failed. Okay, so even this is also fine.
So here we said assert dot assert equals okay, suppose if assertion is also got failed, it will throw exception right. So in the catch block, we will fail the test, we are logging the debug level logs. and also we are logging the error level logs and rest of the times we log only information logs if everything is smoothly going we can just pass info logs okay that's it so wherever you want to log that particular statement to the log file you can put one info log level so this is also most important at the time of writing the test case so portal is a completely blocked okay if the test itself is blocked we can also log portal you can also put logon.debug or logon.txt fail or logger.fortel so whichever levels we have we can specify so fortel okay and if you put fortel okay then level in the xml file you will not get any other logs so most of the times we prefer only two guys either debug or info.
In the general time we use only info so that it will automatically capture all the logs, rest of the lower level logs. But if you need detailed level of logs then we specify debug. That will capture debug and rest of the lower level logs. And if you don't want to generate any logs then you can simply make it off. In the XML file we can simply make it as off.
So in the XML file you can specify all here or you can specify of of means even though if you return all the log messages in the test case still those messages will not be logged into the log file so according to your requirement you can do that even trace is also required trace is also just like a debug it is also giving more detail level of logs this is more higher than debug so debug will give you detail level logs but traces also gives still more detail logs which we cannot understand first of all okay so whatever request are sending to the server through the network all the request will be captured by tracing area all means every log will be generated so not only specifying the log level here but in the test case also we specify the relevant methods then only it will capture yes if you specify info rest of them will be logged automatically okay because uh rest of them comes under the info only right info logs will capture warning error portal so these logs will automatically capture but debug log will not be captured if you put info level in the xml you need to put debug in the xml then only the debug log will be captured otherwise this will not be captured okay all right so we put all the log messages same process we have to follow in every so this is one time configuration so we added xml file and in the base class we have added the code this is for log for j2 code log for j2 code okay that's it this is only one state so from tomorrow if you add any new test case just you can make sure add all the log messages also wherever it is required and once the test is completed i will add one more last thing here this is finished all right so finished so and so test case okay so this is how we can do it so remember this import statement so that you will have so many import here we don't need to import anything in the test case only in the base class we need to okay anyway i'll put them in the notepad so we can guess get them from there anyway i'm sharing the scripts right so you can just go through them or else i can put in the chat box so remember don't import wrong import statements okay these are the import statements we need for the logging all right so only three steps case very simple to do it we added log project xml file in the resources we updated base class and We already have only one test case currently. So we added all the log statements to the current test. So suppose tomorrow if you added a new test case, at the time of adding the test case itself, you can parallelly add the log files, log statements. Now let us run and see whether it is generating the logs or not.
So currently in the log file jit xml file, I put info message so that I will get only information logs. So let us go and execute our test case. close everything so far we have not created xml file so i'm just directly running my test so we are expecting the log file should be created under the logs folder all right run as test ng test still executing no no no the every test case won't have a separate file same next same log for zedford xml file we have to refer we already referred in the base class right so that is applicable for all the test cases by default so in order to do any other configuration for another new test case. So when you create a new test case, just add only log messages, logger.info, logger.debug, logger.info. That's it.
So you don't need to touch the configuration. So log4j.xml we already added and that file is already loaded in the base class. So both have already done. So that is applicable for all the test cases.
You don't need to do any other stuff. Okay, let me run one more time. Right. Word's failing.
can see one log file is already generated in the previous run you can see here because we put the debug right so on failure the debug is also got executed so that is the reason we are getting all these messages and once the log file is got filled so this is a log file which is got filled so these are all uh debug method we put inside the test okay so something wrong in this let me check it just a second yeah message debug and info you will get all this stuff by default depends upon what type of log is specified so currently i specified info and file and file size also you can specify here 5000 i specified as of now if the 5000 is exceeded then it will create another file okay everything is good and base class So we'll try some other URL of the application. I think my URL is not properly working. Guys, I've shared another URL. Can you just try to ping me that URL? We'll try this another URL.
yeah i'll try this one okay so my test is got passed let's go and see the logs so refresh your logs so once you refresh you can see because one why two files are got generated because we specify the size of the file here called 5000 okay if the file size is exceeded then it will take the backup and then it will automatically create a new file okay so if you look at the backup file so it is by default generated testng these are the messages and where is our information messages here it is you can see so starting our registration test case these are messages created by our log for zeta.xml and from here we need to consider so you can see by seeing the log you can see actually which test cases got executed and what time it is got executed time is also specified and these are the logs which we have written so this is a log message click it on my account click it on register link providing customer details violating message and finished that means test case is successfully executed and these are the messages captured from client and server communications all the messages are captured because we put the debug somewhere so if you try to remove this debug let's go to the test Let's remove this. And every time when you run the test case, new messages will be appended to the existing logs. Let's go to the latest one here.
Only one single state. Okay. So let's delete these two and run the test one more time.
Yeah. If you increase the file size, only single file will be generated. okay now it is executed very faster now refresh it is generated one more time so it is captured only information logs because debug error we put in the catch block right so if the test case fails then the debug and error logs will be captured so have you seen any error log here no right any debug or error no only information messages we can see okay let us try to fail the test case intentionally and then we will see what it will do so here i will pass some invalid message uh if you want to in every run it will not create a new log actually because in the real environment we will run multiple group of test cases right together so all the logs will be generated in one single file if the file size is got exceeded then automatically it will create another file that will keep the file and suppose if you run one more time then in the same file the new stuff will be added okay so let us try to increase the file name a file slice let's go back to the xml and here i'll put one more zero fifty thousand and go back xml file now this time i'm intentionally fail the test case and we'll see whether this debug log error log will execute or not so i'll put two more columns so that my test will definitely fail okay done now can go back to the logs refresh now you can see there is only one single file is got generated because we have given a huge size so in the single file itself which is got created what happened so my test is got failed here right yeah my test is got failed now this time we should able to see the error log try to refresh once so starting the test case click on the my account registration link provide a customer details validating expected message so after that it is not executed anything so let us cross check once again so error debug and which level we put here error and debug we put right so error means when i put info error also we will capture but debug we cannot capture because we put info here so let us try to put debug and execute yes if you want to keep old for old old stuff yes obviously that will keep all the files and old data also see i have run one more time in the same log file the entries will be generated. See these are the previous entries and these are the new entries.
So after valid exporter message catch block is not properly handling. Let me try to change it. so other log should execute action okay so we'll do one thing so we'll put one if condition okay if this confirmation message dot equals this one because sometimes we are using assertion right so directly assertion cannot log the information so i'll put this so created so then what i should do is here i will write an assertion etc dot asset true we're expecting true i'm also passing else okay else i can say asset dot s3 is false okay now i'll put this inside the else block okay so in the catch block i put only asset dot fail if any exception comes catch block will execute and fail the test and if exception is not comes then else block will obviously will execute so here i will put error log and debug anything is fine so ultimately we are using the assertion directly right so let's execute and see now so in that case this assertion is not needed because we are already comparing it here and put the session so this assertion is not needed okay so let's delete the file okay so i put some debug execute okay just a second so we failed the test case intentionally by giving an incorrect title incorrect message right it is got failed let's go back and see logs okay now you can see here you will get a error log as well as a debug log so when because we put the debug right so error debug in the in the same else block so you got it here So, validating expected message and test failed and debug. When you put this in the catch block, it is not executed because the catch block itself is not executed. So, after accession, rest of the statements will not be executed, right?
So that is the problem we got earlier. So we put this accession, it's accession failed, rest of the statements are not executed because it is a hard accession. So we can put if else condition inside this, you can use accession like this instead of keeping one single statement.
Now if we get any exception obviously the catch block will execute and this will fail the test and really if that test is got failed because of titles are not matching properly then if else condition will take care of it. So this is how we can simply generate the locks and we cannot understand all these methods all these statements so that these are all the network related commands. So when I do some action on the UI it will hit to the server and between there are so many methods will be called so all these methods are called here they are triggered automatically so this is a one-time setup creating log for j2.xml file and then update base class and go to the test case and add all the messages whichever you want so this is the continuous process for all the test cases we do the same process means we no need to update xml file we no need to change the base class only the test case when i write a new test case we just add the logger messages and once this file is filled with that limit sizes got exceeded then automatically it will create another file with the timestamp so that we can also maintain the history okay suppose if you want to generate the logs in the console window here i want to generate simply go to the log projector.xml file and here instead of reference file you can put the console you can put both also in the console and file but execution will become very very slow we enable the locks i just comment this one so this time the locks will not be generated in the file so the locks will be generated only in the console window okay so old locks will automatically capture it into the log file that's the reason I given the list size here.
So then what happens the suppose earlier already run right so I already captured the logs here. So if you do one more round of execution, these logs will not be deleted still there is there because with the timestamp it will store. So at the end of this log file, the new log statements will be keep on adding it will just basically appending the new logs it is not replacing or is not deleting until unless we deleted the file, the log files will not be deleted.
so old logs in the sense these are the entries of the old logs i will keep these entries again one more time i will run and then we'll see because i put the console right so i can make again file now just observe this time i reduce the file size but the new logs will be keep on adding to the file so over here and let us make the test case passed one more time so world log is there so this is the world log now again i'm running the test one more time so the statements will keep adding to the log yeah so now again if you refresh the logs yeah so world logs will be confined in this backup file so you can see the timestamp also 739 if you go back to here It's not much difference. So old logs also will be maintained in the multiple files. So this is one important stuff we need to have. So this is most important whenever you are trying to find the bugs in your application.
So developer will ask the log file. So simply execute all your automation test cases. You can have 10, 20 test cases and you can get all the messages in the log file. And one more advantage of log file is. you will know exactly what are the test cases are passed what are the test cases have failed and why it is got failed where it is failed so you can easily identify that information okay so whichever step is got failed you can easily identify that yes the old file will be renamed with the timestamp and taking the backup here this is the old file and this is the latest file suppose if you run automation one more time This file will be filled.
Then what happens? This file again take the backup with the timestamp and another automation log file will be generated. Okay.
So let me run one more time. So currently I have two files, right? Automation log is always the latest file and rest of them are the old files. You can see with the timestamp.
So I'm running one more time. Okay. Done.
so if you refresh the logs once again i think second file still exists so this file still not filled so only three statements have got filled so if you run multiple times once the sizes got exceeded it will keep creating multiple files here so old logs you can see in the timestamp files you can see timestamp and the latest logs recent runs you can see in the latest file automation.log okay this is simple logging mechanism we can simply add to the project okay so everybody is clear on this only three steps so time zone and all we need to again configure this xml file so whichever time zone you are running the test that cat time zone will be automatically captured so here i specify the timestamp right so in whichever time zone you are executing on the same time zone the logs will be captured this is the default actually okay right so this is the logs for j stuff so we just added xml file we updated base class and then we have done account station test we have added some log messages and we have created that's it and you need to give the names properly so log for jet xml file should not be changed the file name should be same if you change this file name it cannot create the logs so if you don't want to create any logs simply you can make this as a off okay so if you make it is off so then it will not generate any logs done so now let's move on to the next step so logging is done in the framework so tomorrow if you add a new test case you don't need to do again these steps just you need to add log message to the test case that is enough now third step how to run the test on desired browser or cross browser or parallel testing So this is another most important concept in the test ng we already learned right cross browser testing parallel testing same thing we will try to implement in the framework right. So now we need to first create a new testng.xml file and which contains the test cases and we will pass browser name and also operating system os name these two parameters we are going to pass to the test cases. from the XML file we need to parameterize. As of now we are running only one operating system. But suppose tomorrow if you want to run your test case on the grid environment, we will also pass browser name along with the operating system.
So for now, let me take both the parameter, but I will use only one browser name. Okay. And after that, we need to update base class and then we will create a separate XML file to run the test cases parallelly. So let us do step by step.
So first we need to create XML file and where we want to pass name and operating system as a parameters. Let's go and do that first step. So where to create an XML file inside the project, we can create an XML file. Okay, so I will take this test cases package, because all the test cases whatever is there in the test cases should be part of the XML file.
So I'm directly going create automated generation xml file go to testng convert to test engine so this is my testng file which i'm creating click on the finish yes so now i got a test ng file created so here you can see only currently one test case we have is specified so now we need to pass parameters browser name and then we have to pass operating system so both we need to pass okay so let me so we will maintain the two different xml files one is for running master suit another is for parallel testing okay so what i will do is i will name this as a master.xml you can just save this first so i'll name it as a master.xml right so now we want to pass two parameters operating system and browser name so how we can pass parameters before starting the classes tag we add parameter type right parameter name equal to os means operating system and the value is equal to as of now i'm passing windows when i when i'm using grid concept then i'll try to pass another operating system so for now i'm just passing windows and then another one this is a parameter closing tag okay what is missing let me save the file okay so let me add two parameters one is parameter parameter space name equal to os operating system and the value value is equal to windows and then we have to close this this is one parameter and then we have to create another parameter another parameter this is browser name i can say browser and the value is for now i'm passing one single browser later if you want you can change i can pass chrome okay so what's went wrong test classes class classes tag is closed test tag is also closed everything is fine right we are getting the error here let me just check it so before starting the classes keep these two parameters okay done so we are passing two parameters one is operating system another one is browser so what is the next step we need to receive those two parameters we need to receive where we have to receive these parameters where we have to receive in which method we have to receive these two parameters in the base class setup method right because setup method is responsible for launching the browsers so setup method should receive the browser so in this setup method we have to receive those parameters so how we can receive them just by adding parameters tag so in the last classes we already seen so along with this before class let me add parameters and we are passing two parameters so in the curly brace we specify two parameters one is os same name we have to give second is browser two parameters we are passing and these parameters tag also annotation we have to import from test engine dot annotations now for these two parameters we need to pass we need to specify two variables string os comma string browser i can say Now based on this information we have to launch particular browser and particular operating system. So this operating system variable I will try to use later for now I am using this browser. So whichever browser name we are getting from xml file so that particular browser we have to launch.
So this particular step we have to modify. So before launching the browser here based on the condition we have to launch particular browser. So this statement we need to modify. according to the browser rest of the statement still same right so i write one switch case statement here switch browser and this browser name sometimes we pass capital letters lowercase missile case characters right from xml file so whatever characters we are passing i'm converting into lowercase characters everything into lowercase so there will not be any conflict in that case so if the br dot two lowercase that means here we need to write multiple case if br value or case value if case br value is equal to chrome for example so then what i should do i should execute this statement and then break right suppose case browser name is equal to firefox or browser name equal to edge then driver should be what new edge browser so new edge driver so all the conditions we have to specify here and then break and suppose case browser equal to firefox browser equal to firefox so then driver equal to new firefox driver then break suppose we pass invalid browser name invalid browser name other than these three then default is what i can print something here system dot dot dot println invalid browser name i can print some message and then simply you can say return return why there is a return here so normally in the default block we don't put a break right because after default there is no other statements so return means this will totally exit from the execution because if the browser itself is invalid we no need to continue the further stuff right so we no need to execute all the test cases nothing so here itself we are exiting from the entire execution part so the return method will do that so if we don't put return then what will happen even though it is invalid browser name still it is trying to execute the rest of the stuff so we don't need that right so the return should be there so if the browser equal to chrome then launching the chrome browser if it is the edge then launching the edge driver and if it is the firefox then launching the firefox if it is invalid browser the default will execute we are saying invalid browser name and return return means it will exit from the execution automatically so this particular switch case block will decide which browser we have to launch based on the parameter we passed and once the browser is decided then rest of the statement will execute on the same driver, whichever driver is initiated in this.
on the same driver rest of the statements will got executed. So, this is how we can pass parameter from XML file to setup method at the runtime. So, can we execute this test case directly now?
Can we use execute the test case directly from here? No, because this time the test case is depending on the XML file. So, from the XML file we have to pass the parameters that is os and browser so currently operating system this variable i'm not using so once i use grid concept then i will try to make use of this os also currently i'm using br okay done so now go back to xml file and then execute so i'm passing chrome browser initially so it is executing on the chrome browser fine so let me pass another browser go to xml file so here instead of chrome i'm passing firefox then execute so firefox i don't try okay because it is very very slow always takes a lot of time yeah so now my firefox has got launched now it is doing everything perfectly fine right whichever browser name i am passing it is launching that particular browser and doing the action so similarly you can pass it grow whatever so we can maintain we can make this xml as a master suit means what we can add more number of test cases here later and all the test cases will execute whichever browser you want here okay this is one suppose sometimes we want to do parallel testing i want to execute all the test cases and multiple browsers parallelly that is a specific requirement you don't run them every time you don't run parallelly okay every time you don't run parallel only one round of testing we do parallel execution only one round of testing that too after completion of all the test cases and you will run all the test cases multiple browsers in one shot So, we do parallel testing only one time that was specific requirement. So, we should not disturb this master suite. Let's keep this open.
Now what we need to do is we will create another XML file where we will try to achieve the parallel testing. So, what I can do is I can take the same XML file copy and make another copy of XML file and let's name it as a cross browser testing. Cross browser.
testing.xml cross browser and also parallel both we can achieve this so in this okay so try to give a lowercase characters cross browser testing okay so in this if you want to achieve the cross browser testing then how we can do that suppose i want to execute this in multiple browsers parallelly so what i can do is i can create multiple entries right so i can create multiple entries so let me show you how we can create it so this is from test to test to one entry right so i will take another entry i'll take another entry three entries because i have a three browsers i'm taking three entries okay and soot level you can put thread account suit level keep the thread count you get to five is fine default and you can remove this thread count for test not need okay no need of this thread count for test if you put that in the suit level right so when you put multiple entries there should be different names so this is for what this test is created for what chrome so here the test name i said is chrome test and this test is got created for edge so here i can put name equal to ng test and here third entry i can put firefox and here the name is uh firefox test like this so when i execute this xml file serial execution will happen right one after another first execute in chrome then execute in edge and then it will execute on the file box let's execute serially first run as test ng test. This is same concept earlier we already discussed again it is repeating. So, chrome is done now ng started and after that Firefox will start.
So, do not try Firefox it is very very slow ok now it is started perfect. So, Firefox is also successfully executed. so serial serial execution we have now we we want to make it as parallel so to make parallel what you can do in the suit level we can add one property called parallel equal to tests parallel equal to test so this will make parallel execution so let's execute and see run as test ng test See, this is one browser, this is another browser, this is another browser. So, total three browsers launched parallelly and execution has happened.
See, all three tests got executed and passed. Yes, all parallel testing, all browsers logs will be logged into the log file by default. So, some execution is happening, immediately logs will be created. So, what is the thread count? the last classes I already explained this what is a thread count means.
So because we are running multiple tests, so we need to accommodate multiple memory locations. So when I say thread count five, five locations will be created. And each location each test will be executed.
So this will be helpful if you if you want to run multiple test cases parallelly. So for that reason, we put thread count. So don't increase the thread count more than five because it will again become unstable. So two to five is enough more than if you have more 50 100 test cases, more than 50 more than 100 test cases five is required.
And if you have only less number of test cases are less if you have three, four or five test cases, that count two is enough can necessarily don't allocate more memory to the less number of test cases. Right, so we are achieved the cross browser testing also. So whenever you want to execute your test cases, multiple browsers, you have to use this XML file. So this is the next step. So let's go and read the steps once again.
So we created an XML file to run the test cases and parameterize browser name and OS to the base class setup method. And then we have updated base class setup method by adding switch case condition. And switch case condition will decide which browser we need to launch. And then we will maintain a separate XML to run multiple browsers.
So these are the steps. so all xml files we should be creating at the project level itself we should not create in any other packages okay the xml files are the project level because it will deal with all the test cases every file so xml files should be part of project level not in the package level okay fine so these are the steps now let us move on to the next one Very easy reading common values from config.properties file. So earlier we have already seen what is the use of config.properties file, why we need to go with properties file, common data.
Suppose if any test case, all the test cases require some common data, common variables. For example, URL of the application, login details, customer IDs. So these are all commonly required for all the test cases and those values are always the same. So instead of writing those values in every test case, hard coded values, we will specify them in the properties file. And we will use those values in multiple test cases, right?
That is an advantage of creating the properties files earlier already explained this in detail. So one more time, I'm going through this, just try to understand this, what is a user property file. So let us say I have multiple test cases, TC one, TC two, TC three, and so on. in every TC we have some common variables are required like URL, username, password.
So every test case is required. So instead of writing these in every test case, we will create a separate property file and here we will write all the values key and value pairs. And this from this particular file, we will read the data in every test case. Okay, this is the usage of property.
So let us create a separate config dot property file. where we will create all the common variables. Okay, so where we have to keep this config.properties file again under the same resources because this is also resources file.
So config.properties file we need to create. Let's go and create config.property. properties okay so in the confederate properties i will put some common variables so which are required for all the test cases okay so i'll put some variables here and properties file will follow key and value base right so in the last classes we already discussed so i put app url application url email address password and some product name so these variables we will use in the further test cases login test case search product so we'll create some more test cases that time i will try to use these variables for now i put some app url so whichever url you want to put you can keep this so as of now i have used this particular url okay if you want both you This is also an app URL, you can make it as app URL one, this is app URL to app URL to okay, keep both which are URL you want, you can use it.
So this email password search product name, I will use these variables later. So whatever variables are commonly required in multiple test cases, you can keep all the variables here inside the config.properties file. So this is the first step. Then we have to load this file and read the values from this variables.
So that step we have to do inside the base class setup method itself, because setup method will execute first before all methods, right. So the config properties file also we have to load at the beginning stage. So here I will write some piece of code for loading configuration file loading config dot properties file, sorry. so loading config dot properties file so for that we need to write a piece of code so how to load configure properties file in the last classes we already seen so we have to use a special class so what is the class here i will put public properties class okay properties p i'm taking some variable called p so we need to create a properties class variable so by using this p i can load properties values and property file and get the file so here i'm writing some piece of code so i'm using a special class you can use file input stream or file reader whatever class you want so i'm using file reader class this is also another class which is there to read the file file reader file equal to new you can use file input stream also no problem so file reader And here we have to specify where exactly your configuration file is present. So where exactly it is present under SRC test resources, configure properties.
So that is the location right. So here I can say dot slash slash dot slash slash is representing current the project location in the current project directory SRC test resources against the SRC slash test slash under resources. the file name is what config.properties file config.properties so you need to specify this so file reader class we have to input this is alternative class for file input string this will throw exception just add it so we are getting the file into a variable so this variable is representing the property file so now we need to load this file how to load it first we create an object of the properties class p equal to new properties And inside this P we have a one method called load and we want to pass a file p dot load of file. So this command will load the property file.
So once it is loaded, by using this P, we can capture the data from the properties file. So now if I go back and see, as of now, we are hard coded these URLs, right. So instead of this, I want to get it from the property file.
So what we should do now So simply diver dot get instead of hard coding this data. I'll get it from the properties file. So we already loaded this file by using P here.
So P is represented the property file. So now we can simply say P dot get a property of and which property you want to capture app URL one or app URL to currently I'm using app URL to that variable I can specify. So whichever variable is specified here in the double quotes, that value will be captured and will be launched by this get method.
So here reading value or reading browser reading url from properties file okay like this tomorrow if you want to capture any other values from properties file simply use this command p dot get property of username p dot get property of password p dot get property of customer url like like this so whichever properties you specified in the properties file you can get everything by using p dot get property okay so now we have replaced the hardcoded values by reading the data from the properties file as of now we have only this variable so later once we added more test cases we will keep adding more number of variables in the properties file very simple step so what we have done is we just added configure properties file in the src test resources Then we have updated base class setup method to load the properties file. And then we have captured the hardcoded values, test cases like username, password, URL and so on. Okay, so this is how simple three steps.
So wherever the values we want to use, we can just get them into the from the properties file. So three steps done. So let's go and execute the test case one more time. close properties file close base class directly go to xml file i'll again go to master.xml file and then execute so this time the url will be taken from the properties file perfect so now it is url is reading from the properties okay done so this is a step by step process of implementing the framework so far four items we have covered First time we have added a base test case, then we have added logging mechanism to the framework, then we have added cross browser and parallel testing to the framework, then also we have added config.properties file.
Okay, so few things we have added to the framework by taking one single test case. So tomorrow, we'll take one more test case login test case. And then we will try to do some more stuff. Like we will try to add some more page object classes.
So one more test case we will try to add then we can execute and after that I will show you how we can do the data driven test case how we can add data driven test case and then how we can add a grouping part in the framework and then how we can add extend report. So this is a step by step process of developing the framework. So at the time of practicing also you do the same order.
So don't jump here and then first don't do cross browser and then don't do this log4j. So whichever sequence I mentioned here, if you go to the same sequence if you follow the same sequence you will not have any confusion everything will be fine and one more thing until unless one step is successfully completed then don't go for the next step if it is successfully completed then only go with the next step if it is not completed then identify the issues solve it okay make sure it is working fine and then go to the next step don't club all the steps in one single shot okay so this is a way you can implement the framework so if you go to this step-by-step process there will not be any confusion so i will upload all the files in the step-by-step even folders i will upload for adding logs to test case i will upload one folder for running test cases on desired browser i will add another folder and folder wise upload in the google drive okay you can get it from there and also i will upload this document today you can get it all right so let us stop here for today's session just complete these steps second third and four i hope most of them have already completed step number one so tomorrow uh you complete this one second third and fourth and then we'll proceed with the fifth step okay that's it for today's session i will stop i have taken lot and tomorrow we will continue