Session 50: Selenium with Java | Hybrid Framework | Log… — Transcript

Learn how to implement logging in Selenium with Java hybrid framework, covering log types, levels, and benefits for automation and application testing.

Key Takeaways

Logging is essential for tracking test execution events and debugging automation scripts.
There are multiple log levels that determine the detail of logged information.
Log files provide a permanent record useful for developers to analyze issues beyond UI steps.
Automation projects should maintain their own log files for better defect tracking and security.
Choosing between console and file logging depends on the need for permanence and ease of sharing.

Summary

Introduction to logging in automation testing with Selenium and Java hybrid framework.
Explanation of what logs are and the importance of logging events during test execution.
Distinction between application logs and automation logs with their purposes.
Benefits of log files including defect analysis, security monitoring, and tracking user actions.
Overview of different log levels: Trace, Debug, Info, Warning, Error, Fatal, Off, and All.
How log levels control the granularity of logged information and their hierarchy.
Comparison of logging outputs: console logs vs. file logs, with file logs preferred for permanence and sharing.
Use cases where developers request log files to better understand and fix defects.
Configuration of logging behavior via XML files and setting appropriate log levels.
Importance of maintaining logs in automation projects for easier debugging and monitoring.

Full Transcript — Download SRT & Markdown

Speaker A

All right, so in the previous class, we started the implementation of the framework. As part of that, we created a folder structure, and then we took one test case on registration. We did some basic stuff, created some page object classes and test cases, and executed them.

Speaker A

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 uh what

Speaker A

Now, today we'll go on to the next step: adding logs to the test case. First of all, we'll understand what a log is, how many types of logs we can generate, and what the advantages of generating log messages are. So, we'll understand some basics about logs, and then we will see how we can generate logs.

Speaker A

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

Speaker A

Basically, what does logging mean? We can record all the events in the form of text, which is simply called the logging process—recording all the events in the form of text. So, what does it mean? Suppose whenever you are executing your test cases, your test case is doing some event. Suppose it is launching your application, it is logging in registration, or it is performing some actions on the application or some events.

Speaker A

logs so application logs means what when I uh any user is performing some actions on the application back in the backend side the log files will be generated so whatever actions are done by the user or customer on the application every even will be logged into the lock file at the backend side but

Speaker A

We can log all of those events in a text file in the form of text, which is called the logging process. What is the advantage of getting the log file? What is the advantage of generating the log file? Normally, there are two kinds of logs: application logs and automation logs.

Speaker A

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 right whichever user is

Speaker A

Application logs mean when any user is performing some actions on the application, back-end log files will be generated. Whatever actions are done by the user or customer on the application, every event will be logged into the log file at the back end. But as a user, we cannot see exactly what is being logged, but it will internally log everything.

Speaker A

analyze the lock file they can monitor the lock and it is also a kind of a security mechanism which is provided to the application okay that is called lock 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

Speaker A

The main advantage of using a log file is, suppose in real-time applications in production, any user is doing some unauthorized activity. In that particular case, they can easily track the information and take immediate action or necessary steps, whichever is required. They can block the account or hold that account, something like this.

Speaker A

loog file so sometimes the developer will ask to provide the loog 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 Q environment but the same defects may not be reprodu in the

Speaker A

Basically, the log file will be used to track information about whichever user is doing whichever event or action on the application. They can track everything in the log file. They maintain the log files at the back end, and they can generate the log files every time, every second. There is a specific team that can analyze the log file, monitor the log, and it is also a kind of security mechanism provided to the application.

Speaker A

the issue and accordingly they can fix the buck so that is the main advantage of using log file so in automation also we can create our own log log files okay now these logs are different levels there are different levels of log levels uh what are the different log levels so all trays debug

Speaker A

That is called a log file. When you come to automation, our automation project also maintains log files because we can also log all the events 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.

Speaker A

j. XML configuration file so that leave for now so the main six 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

Speaker A

What is the benefit of the log file in automation? Suppose tomorrow any test case is failed; that information is also part of the log file. 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 be reproducible in the QA environment, but the same defects may not be reproducible in the dev environment.

Speaker A

if you said log level is info then you'll get info logs along with warning error FAL so lower level logs also you will get along with the info similar if you set log level is equal to one then

Speaker A

In those cases, the developer will ask you to provide the log file. Along with the defect information, like test case steps, screenshots, you will provide everything. Similarly, you will also provide the log file, and the developer can understand the log file, analyze the issue, and accordingly fix the bug.

Speaker A

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

Speaker A

That is the main advantage of using a log file. So, in automation, we can create our own log files. Now, these logs have different levels. There are different log levels. What are the different log levels? Trace logs, debug logs, info logs, warning logs, error logs, fatal logs. These are the different logs—three, four, five, six types of logs.

Speaker A

generate the log fun 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'll see some

Speaker A

These are the six types of logs you have: trace, debug, info, warning, error, fatal. These are called log levels. Suppose if you set the log level as trace, then you will get all types of logs: trace, debug, info, warning, error, fatal. You will get all types of logs.

Speaker A

inside the file it is is easily uh download and we can easily share the file to the development and this is available permanently but when you 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

Speaker A

Suppose if you set the log level as debug, then you will get all the levels from debug to lower levels. Suppose if you set the log level as info, then you'll get info logs along with warning, error, fatal. So, lower-level logs also you will get along with info. Similarly, if you set the log level as error, then you will get error and fatal logs.

Speaker A

available permanent if you run the test case one more time the old logs will be remoted 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

Speaker A

If you set the log level as off, then you will not get any log messages. If you set the log level as all, then you will get all types of logs. These are the options which we can set in the log4j XML 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.

Speaker A

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 forj 2.xml this is the main important file in this file

Speaker A

So, we understood what logging is, what the log levels are, and where we have to set this log level. There are two things we need to understand: appenders and loggers. What are appenders and what are loggers? These are the terminologies we need to understand.

Speaker A

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 F now let me show you step by step so if I go to their official website what is this log for J just type Apachi log for J2 so

Speaker A

Appender is nothing but it describes where exactly we want to generate the log file. We can generate the log file; we can generate the logs in the form of a file, or we can generate the log messages inside the console. When I run the test, you'll see some messages in the console window, right?

Speaker A

there are a lot of content is even developers also will use the same concept for generating the application Mars so here the main important thing is we need to add a dependency in the p. XL file so by default you won't get this you need to add required dependencies in the formex so

Speaker A

We can generate the log messages inside the console window, or we can create a separate file, and all the log messages will be created inside the file. But which one do we prefer? We always prefer the file. Why? Because if you create log messages inside the file, it is easily downloadable, and we can easily share the file with the development team. This is available permanently.

Speaker A

core and lock for J iph 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 I go back and see A1 repository and uh okay so there are multiple versions are there you can see Alpha Beta beta

Speaker A

But when you generate log messages in the console window, these logs are available only at runtime. As soon as you run the test, you need to copy all the logs manually from the console window, then paste them into a file, and then share it with the developer. This is a lengthy process, and these logs will not be available permanently. If you run the test case one more time, the old logs will be removed.

Speaker A

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 number that is so 223 1 223 1 and here this is also same number so 2231 this is the latest version

Speaker A

This is not preferable. Where do you want to generate the logs? Always, we generate the logs in the file itself. So, who will decide where you want to generate the logs, either console or file? Appendenders will decide that. There is something called appenders, and these appenders decide where to generate the logs.

Speaker A

there okay so I'll add this here in the chart box you can get it okay so once you added these dependencies we will get a log for J2 dependencies so library is ready and once you done so we can just try to update the project once go to May one then update

Speaker A

Now, something we have called loggers. What is a logger? The loggers decide what type of logs we have to generate, like at which level of logs we have to generate. That is decided by the loggers. So, this is the basic understanding which we need to have.

Speaker A

that file under SRC test resources 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 j.x if you they if you go back to their

Speaker A

Now, let us look at how we can generate the logs for our automation. To generate the logs for our automation, only three steps: one is we need to have one configuration file, log4j2.xml. This is the main important file. In this file, we have to specify appenders and loggers.

Speaker A

give a sample templates but these templates are not exactly accurate your automation projects we need to do some customization okay so some people will use uh XML file log4j2.xml some people will use log for J2 property file also we can use but most of the times we prefer XML file okay so they

Speaker A

That file contains the appenders and loggers: where you want to generate the log files and what level of logs you want to generate. That information you can specify inside the log4j2.xml file. This is a configuration file.

Speaker A

SRC test resources so let me get that particular file so loog forj 2.xml the file name should not be changed okay the file name itself loog forj 2.xml because this XML file will be loaded by log forj so log forj will remember this the file only with this name so we should not change that

Speaker A

Accordingly, we have to update the base class and account registration test. We need to add log messages because the same log messages will be logged into the log file. Now, let...

Speaker A

everything new just 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

Speaker A

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

Speaker A

it is so you can see two main sections here from here to here this is called upend section this is the loggers section so upenders 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 loggers now what I said appenders

Speaker A

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

Speaker A

loggers we have to specify the which level of log we have to generate and up under 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

Speaker A

so then this appender reference will use this rolling file or when you say console here then this app 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

Speaker A

have to generate the logs and loggers will decide what level of logs we want to generate and in appenders we have a console and rolling file and which one we have to choose that you can specify in the logger section in the logger section appender reference tag is there here we

Speaker A

can specify the reference file or console and if you want to generate in a both console and file then you can enable the statement app reference reference equal to console then app reference reference equal to file so both entries you can specify and which level of logs you can generate

Speaker A

that you can specify in the level here so here I'm mentioned all the levels where you can specify all or you can specify traes or you can specify debug info War error so whichever level of logs you want

Speaker A

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

Speaker A

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 do/ logs means what do slash is representing in the current project directory

Speaker A

inside this logs folder so in the logs folder it will generate the logs 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 exm so here we are specifying the base path

Speaker A

and that base path slash the file name of file is automation log file his name is automation.

Speaker A

log okay because the file should have some name right so automation. log and this log file we will generate with the time stamp because every time it will generate uh same all the entries will be logged in the one single log file okay but but if the log file size is got exceeded it will maintain

Speaker A

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 Tim stamp Dot Lock so base path automation iphon with the time

Speaker A

stamp this is a format time format do log so this is a file name okay this is the format as I said is a template which is provided by apach right and if you not understood this you don't need to worry

Speaker A

at all so you need to just understand only this part loggers 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

Speaker A

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

Speaker A

so the debug is log level which will capture all the transaction between the application and your backend system all throughout the network whatever request 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

Speaker A

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 anytime developer is asked for debug log then you can put this as debug and

Speaker A

run your test cases then it will generate the debug log okay so this is a process yes so the base path is basically a variable okay so there we specify do/ loocks do/ is a current location and logs is a folder name which we specified so the log files will be generated inside the logs

Speaker A

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 War error FAL messages and tray and debug is very very detailed level of logs means what they will also capture the transactions between client and

Speaker A

server in between whatever transportation is happening all the client request will be captured that is very very detailed log so that we can understand we cannot understand that log first of all only developers can understand they can analyze the log and when they put info so

Speaker A

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 as debug log and

Speaker A

they can execute okay so this is a 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

Speaker A

Automation and you can use it this is a just a template configuration file as I said right the configuration file this template also provided by Apache pii 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

Speaker A

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 do XML file this is a configuration file so this

Speaker A

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

Speaker A

want to create in 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 no problem all right so this is all about XML

Speaker A

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 apach Pui website so they provided them some some files you can see here so this is appender section this is the loggers section

Speaker A

and here they provided appender reference so this is simple one configuration file almost to same 80 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

Speaker A

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

Speaker A

enable the debug mode it 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 war or error so these logs will capture only only your automations okay

Speaker A

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

Speaker A

now we need to just update our base class because we just keeping the XML file will not create a log files so we have to write some piece of code which will generate the lock file okay we need

Speaker A

to do some configuration so how we can update the base 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

Speaker A

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

Speaker A

that will read the configuration from the ml 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

Speaker A

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

Speaker A

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

Speaker A

okay so how to load this Base Class sorry how to load this log forj 2.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

Speaker A

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 WR import the right package so this should be ported from org. ap. loging dolog for

Speaker A

J.C this is a package okay so just import this and 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 Apachi do loging dolog forj do cor. logger so let me see is there any other

Speaker A

package okay sorry uh not this this is a one for loger okay I think everything is same all right so let's keep this package for not so first the first thing so this is the new package we have

Speaker A

to import it for logger so this is a step we need to add for log for this is for log for step now in the base class in the setup method we have to use this variable logger so before creating the driver

Speaker A

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

Speaker A

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

Speaker A

this is always representing the class right so this dot get class this is a method so this particular method will get the class name and for that particular class it will get the logger and store into into the variable so this variable we have to use to generate the logs for every test

Speaker A

case so put the semal so this also we need to uh type logger to logger just a sec I think one second guys I think this is not the right one to import just a okay so these are the two packages guys remember so by Mist if you import any other package it

Speaker A

won't work remember this or else just copy paste from here so loog for this is also for loog forj import so the these are the two special Imports we required for log purchase because there are so many classes are there so many packages so you will be confused at the time of importing

Speaker A

so you need to carefully do it so logger equal to log manager. getet logger and here we specify the class dynamically we 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're doing parall so don't do that so

Speaker A

listen first so we pass the class here and log man this is the statement which we have to use to load the log forj 2.xml file so this will automatically get the log file J to XML file because it will Al always fetch in the resources folder there's a default path which is already

Speaker A

configured in the log for J XML so log for J XML file will automatically get it into the variable okay so log manager. getlogger this.g class and this logger 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

Speaker A

log forj 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 last class we already created go to the test case now if I look

Speaker A

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

Speaker A

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

Speaker A

methods you can see here uh you can find info method you can find debug method you can find Trace okay how many log levels we have those many type of methods we have here so we already discuss some log levels right so debug Trace info warning error foral so for these levels

Speaker A

the different methods are there so those methods we can access from the logger so for example here I just want to log information message then I can say logger doino loger do 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

Speaker A

so starting test case because this message will be displayed in the log file okay this says by seeing the message we will understand this test case is started okay and say message we can repeat everywhere suppose uh for example here I'm launching my homepage and clicking on

Speaker A

my account and then clicking on the register right so you can write another message here Lo a.info and here we 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 comments right so all those comments we can

Speaker A

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

Speaker A

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 doino validating expected message this is another log okay you can put whichever format you want to

Speaker A

write you can write that that's a simple message okay so it should be more easy to understand everyone so simple language and whatever you want to put you can okay for example if ass is got failed then I want to log error message in the error message in the log file right so then

Speaker A

what you can do is uh 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

Speaker A

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 TR catch so from here everything you keep inside the tratch block and from here to here everything because tomorrow if any exception comes in any steps it will

Speaker A

automatically handle so here he will write a catch catch and whatever type of exception commonly we'll 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

Speaker A

but if something is got failed catch blog 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

Speaker A

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 uh log debug debug level logs we require so that

Speaker A

only by specifying the debug option in XML is not enough okay if you specify debug here that it's is not enough in our test case also we need to write a debug message log I can say logger dot

Speaker A

one error message I'm logging and one debug message also I'm logging so test failed and here I'm writing debug logs 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 Asser do fail

Speaker A

okay so even this is also fine so here we said asset. asset equals okay suppose if s 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 locks and also we are logging the error level locks and rest of the

Speaker A

times we log only information locks if everything is smoothly going we can just pass info locks okay that's it so wherever you want log that particular statement in the log F you can put one info log level so this is also most important at the time of writing the test case so foral is a completely

Speaker A

block okay if a test itself is blocked you can also log FAL you can also put log. dbug or logal do fail or log. foral so whichever uh levels we have we can specify so foral okay and if you put

Speaker A

foral okay then level in the XML file you will not get any other locks 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 automatic

Speaker A

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 locks 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 is off so in

Speaker A

the XML file you can specify all here or you can specify off off means even though if you return all the log messages in the test case still those messages will not be logged into the lock file so

Speaker A

according to your requirement you can do that even tra is also required tra is also just like a debug it is also giving more detail level of locks this is more higher than debug so debug will give you

Speaker A

detail level locks but traes also give still more detail locks 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 traing area all means every log will be generated so not only specifying

Speaker A

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

Speaker A

will automatically capture but debug log will not be captured if you put info level in the XML F you need to put debug in the XML file then only the debug log will be captured otherwise this will not

Speaker A

be captured okay all right so we put all the log messages same process we have to follow in every test case so this is onetime configuration so we added XML file and in the base class we have added

Speaker A

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

Speaker A

it is required and once the test is completed I will add one more last uh 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

Speaker A

import anything in the test case only in the base class we need to import 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

Speaker A

uh import statements okay these are the import statements we need for the loging all right so only three steps Cas very simple to do it we added log for J XML file in the resources we updated Base Class and we already have only one test case currently so we added all the

Speaker A

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 par add the log fils log statements okay now let us run and see whether it is generating the logs or Not So currently in the log for J XML file I put

Speaker A

info message so that I will get only information locks 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 expecting the log file should be created under the log folder all right run as test NG test

Speaker A

okay still executing no no no the every test case won't have a separate file same same log for 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 you don't need to do any other other configuration for another

Speaker A

new test case so when you create a new test case just add only log messages logo. info logo. dbug log. that's it so you don't need to touch the configuration so lock for J XML we already added and that file is already loaded in the base class so both have already done so that is applicable

Speaker A

for all the test cases you don't need to do any other stuff okay let me run one more time right what's failing can see one log f is already generated in the previous run you can see here okay because we put the debug right so on failure the debug is also

Speaker A

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

Speaker A

it just a second yeah me debug and info you will get all this stuff by default depends upon what type of log you specify So currently I specified info and file and file size also you can specify here 5,000 I

Speaker A

specified as of now if the 5,000 is exceeded then it will create another file okay everything is good P class okay so we'll try some other URL of the application I think my URL is not properly working guys I shared another URL can you just try to ping me that URL we'll try this another UR

Speaker A

yes 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 uh we specify the size of the

Speaker A

file here called 5,000 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

Speaker A

generated test NG uh 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 your uh log for J XML and from here we need to consider so you can see by seeing the log

Speaker A

you can see actually which test case is got executed and what time it is got executed time is also specify and these are the logs which we have return so this is the log message clicked on my account clicked on register link providing customer details valuing message and finished

Speaker A

that means test Cas 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

Speaker A

run the test case new messages will be appended to the existing lock so 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 more time yeah if you increase the file size only single file will be

Speaker A

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 uh error logs will be captured so have you seen any error log here no

Speaker A

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 uh in every run it will not create new log actually because

Speaker A

in the Real Environment we will run multiple group of test cases right together so all the logs will be generated 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

Speaker A

in the same file the new stuff will be added okay so let us try to increase the file name a file size let's go back to the XML and here I'll put one more zero 50,000 and go back XML

Speaker A

file now this time I'm inally fail the test case and we'll see whether this debug log will 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

Speaker A

one single file is got generated because we have given H 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

Speaker A

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 one again so error debug and which level we put here error and debug we put

Speaker A

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 uh old stuff

Speaker A

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

Speaker A

so after valid experted message catch block is not properly handling let me try to change it so other log should execute actually okay so we'll do one thing so we'll put one if condition okay if this confirmation message dot

Speaker A

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 Asser dot asset true we're expecting true I'm also passing

Speaker A

else okay else I can say asset do asset is false okay now I'll put this inside the else block okay so in the catch block I put only asset. 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

Speaker A

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 assertion so this assertion is not

Speaker A

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 a incorrect title incorrect message right it is got failed let's go back and see logs

Speaker A

okay now we 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

Speaker A

message and test fail and debug when you put this in the catch block it is not executed because the catch block itself is not executed so the after assession rest of the statements will not be executed right so that's is the problem we got earlier so we put this assession it's assession f

Speaker A

rest of the statements are not executed because it's a hard assertion so we can put if El condition inside this you can use assertion like this inste keeping one single statement now if you get any exception obviously the catch block will execute and this will fail the test and really

Speaker A

if that test is got failed because of titles are match not matching properly then if else condition will take care of it okay so this is how we can simply generate the logs and we cannot understand all these methods all these statements so that these are all the network related commands so

Speaker A

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 have triggered automatically so this is a one-time setup creating log forj 2.xml file and then update Base Class and go to the test case and

Speaker A

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 don't need to update XML file we don't need to change the base class only the test case when I write a new test case we just add the logger messages

Speaker A

and once this file is filled with the limit sizes got exceeded then automatically it will create another file with the time stamp 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

Speaker A

go to the log for gener XML file and uh 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

Speaker A

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 V logs will automatically captured into the log file that's the reason I given the list size here so then what happens the suppose earlier

Speaker A

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 time St it will stored so at the end of this log file the new log statements will be keep on adding it will just basically

Speaker A

appending the new locks it is not replacing or is not deleting until unless we deleted the file the lock files will not be deleted so old logs in the sense these are the entries of the old logs I

Speaker A

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 go here and let us make the test case pass

Speaker A

one more time so w log is there so this is the Old 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

Speaker A

yeah so V logs will be conf finded in this backup file so you can see the time stamp also 7:39 if you go back to here 739 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

Speaker A

most important whenever uh you are trying to find the bugs in your application so developer will ask the log file so simply execute all your autom 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

Speaker A

exactly what are the test cases of pass what are the test cases are 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

Speaker A

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 time stamp and another automation log file will be generated okay so let me run one

Speaker A

more time so currently have a two files right automation log is a always latest file and rest of them are the old files you can see with the time stamp so I'm running one more time okay done so if you refresh the logs once again I think second file still exist so this file still

Speaker A

not filled so only three statements have got F 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 time stamp and the latest logs recent runs you can see in the latest file automation.

Speaker A

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 time zone will be automatically capture so here I

Speaker A

specify the Tim stamp right so in whichever time zone you are executing on the same time zone the logs will be captured this is a default actually okay right so this is the logs for J stuff so we

Speaker A

just added XML file we updated base class and then we have done account registration 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 J XML file should not be changed the file name should be same if you change this file name

Speaker A

it cannot create the locks okay so if you don't want to create any locks simply you can make this as a off okay so if you make it is off so then it will not generate any locks done so now let's

Speaker A

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

Speaker A

case that is enough now third step how to run the test on desired browser or cross browser or parel 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

Speaker A

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

Speaker A

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

Speaker A

class and then we will create a separate XML file to run the test cases parall so let us do step by step so first we need to create XML file and uh where we want to pass name and operating system

Speaker A

as a parameters let's go and do that third 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

Speaker A

going create automatic generation XML file go to test NG convert to testng so this is my test NG file which I'm creating click on the Finish yes so now I got a test NG file created so here you

Speaker A

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 uh XML files one is for running master suit another is

Speaker A

for parallel testing okay so what I will do is I will name this as a master. XML can just save this first so I'll name it as a master. XML right so now we want to pass two parameters operating

Speaker A

system and browser name so how we can pass parameters before starting the classes tag we add parameter tag 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

Speaker A

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 time okay what is missing let me save the file okay so let me add two parameters one is parameter parameter

Speaker A

space name equal to O 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

Speaker A

for now I'm passing uh one single browser later if you want you can change I can pass Chrome okay so what's WR wrong [Music] test classes class classes like is closed test tag is also closed everything is fine right we are getting the error here let me just check

Speaker A

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 step we need to receive those two parameters we

Speaker A

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 why because setup method is responsible for launching the browsers so setup method

Speaker A

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 stag so in the last classes we already seen so along with this before class let me add parameters and we are passing two

Speaker A

parameters so in the CBR we specify two parameters one is OS same name we have to give second is browser two parameters we are passing and the parameters tag also annotation we have to import from test engine. annotation now for these two parameters we need to pass we need to specify

Speaker A

two variables string OS comma string browser I can say BR now based on this information we have to uh launch particular browser and particular operating system so this operating system variable I will try to use later for now I'm using this browser so whichever browser name we are getting from XML

Speaker A

file so that particular browser we have to launch so this particular step we have to modif okay 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

Speaker A

right so I'll write one switch case statement here switch browser and this browser name sometimes we pass capital letters lower Miss case characters right from XML file so whatever characters we are passing I'm converting into lowercase characters everything into lower case so there will not be

Speaker A

any conflict in that case so if the br. two lower case 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

Speaker A

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

Speaker A

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 print invalid browser name I can print this some message and then simply I can say return return why there is a return here so normally

Speaker A

in the default block we don't put uh break right because after default there is no other statements so return 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 don't need to execute all the test

Speaker A

cases nothing so here itself we exiting from the entire execution part so the return method will do that so if I 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

Speaker A

should be there so the browser equal to Chrome then launching the Chrome browser if it is a edge then launching The Edge driver and if it a 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

Speaker A

will exit from the execution automatically so this Butler 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

Speaker A

driver rest of the statements will got executed so this is how we can pass parameter from XML file to setup method at the run time okay so can we execute this test case directly now can we execute the test case directly from here no because this time the test case is depending on the XML file so

Speaker A

from the XML file we have to pass the parameters right 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

Speaker A

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 don't try Okay because it is very very slow always takes a lot of

Speaker A

time yeah so now my Firefox has got launched now it is doing everything perfectly fine right whichever browser name I'm passing it is launching that particular browser and doing the action so similar you can pass Ed whatever so we can maintain we can make this XML as

Speaker A

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 parall that is

Speaker A

a specific requirement you don't run them every time you don't run parall okay every time you don't run parall only one round of testing we we do parallel execution only one round of testing that two after completion of all the test cases and you will run all the test

Speaker A

cases multiple browsers in one shot so we do parel testing only one time that was specific requirement so we should not disturb this master suit 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

Speaker A

do is I can take the same XML file copy and make another copy of XML file okay and uh let's name it as a cross browser testing okay cross browser testing. Exel cross browser and also parallel both we can achieve this so in this okay so try to give a lowercase characters cross browser

Speaker A

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 parall so what I can do is I can create multiple entries right so I can create multiple

Speaker A

entries so let me show you how we can create it so this is from test two test to one entry right so I will take a another entry I'll take another entry three entries because I have a three browsers I'm taking three entries okay and suit level you can put thread count suit

Speaker A

level keep the thread count equal to five is fine default and you can remove this thread con for test not need okay no need of this thread con for test if you put that in the suit level right so when you put multiple entries there should be different names

Speaker A

so this is for what this test is created for what Chrome so here the test name I set is Chrome test and this test is got created for Edge so here I can put name equal to Edge test and here third

Speaker A

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

Speaker A

test this is same concept earlier we already discussed again it is repeating so Chrome is done now EDG started and after that Firefox will start so don't try Firefox it is very very slow okay now it is started perfect so Firefox is also successfully executed so serial serial

Speaker A

execution we have Achi now we we want to make it as parallel so to make parallel what we can do in the suit level we can add one property called parallel equal to test parall equal to test so this will make parallel execution so let's execute and see Runners test NG

Speaker A

test see this is one browser this is another browser this is another browser so totally three browsers launched parall and execution is happened see all T three tests are got executed and pass yes all F all parallel testing all browsers logs will be logged into the log file by default so

Speaker A

some execution is happening immediately logs will be created so what is a thread count the last classes I already explained this what is a thread count means so because we are running multiple test so we need to accommodate multiple memory locations so when I say thread count five five

Speaker A

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 parall 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 2 to five is

Speaker A

enough more than if you have more 500 test cases more than 50 more than 100 test cases five is required and if you have only less number of test cases or let say you have three four five test

Speaker A

cases thread count two is enough 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

Speaker A

go and read the steps once again so we created an XML file to run the test cases and parameterize browser name and W to the base class setup method and then we have updated base class setup method by adding switch case condition and switch case condition we'll decide which browser we need to

Speaker A

launch and then we'll maintain a separate XML to run multiple browsers pad 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

Speaker A

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

Speaker A

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 required some common data common variables for examp example URL of the application login details

Speaker A

customer IDs so these are all commonly required for all the test cases and those values are always same so instead of writing those values in every test case hardcoded values we will specify them in the properties file and we will use those values in multiple test cases right that is an advantage

Speaker A

of creating the properties file earlier already explained this in detail so one more time I'm going through this just try to understand this what is a use of property file so let us say I have multiple test cases tc1 tc2 TC3 and so on in every TC we have some common variables are

Speaker A

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 he will write all the values key and value Pairs and this from this particular file we will read the data in every test case

Speaker A

okay this is the usage of property file so let us create a separate config or property file where we will create all the common variables okay so where we have to keep this config do properties file again under the same resources because this is also resources file so config

Speaker A

do properties file we need to create let's go and create config do property so go go to resources and creating new file and the name is config dot properties okay so in in the config properties I will put some common variables so which are required for all the test cases

Speaker A

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

Speaker A

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've

Speaker A

used this particular URL okay if you want both you can keep this is also an app URL you can make it as app URL one this is app URL 2 app URL 2 okay I keep both whichever URL you want you can use it so

Speaker A

this email password search product name I will use these variables later so whatever variable are commonly required in multiple test cases you can keep all the variables here inside the configur properties file so this is the first St then we have to load this file and read the

Speaker A

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 configur properties file also we have to load at the beginning stage so here I will write some piece of code for loading

Speaker A

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 uh we already seen so we have to use a special class so what is a class here I will

Speaker A

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 cod so I'm using uh a special class you can use

Speaker A

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

Speaker A

configuration file is present so where exactly it is present under SRC test resources config do properties so that is the location right so here I can say do SL slash do SL slash is representing current project location in the current project directory SRC test resources I can say SRC slash

Speaker A

test slash under resources the file name is what config do properties file config dot properties so you need to specify this so file reader class we have to input this is alternative class for file input stream this will throw exception just add it so we are getting the file into a variable so this

Speaker A

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

Speaker A

method called load and we want to pass the file P do 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

Speaker A

so now now if I go back and see as of now we are hardcoded these URLs right so instead of this I want to get it from the property file so what we should do now so simply driver. getet

Speaker A

instead of hardcoding this data I'll get it from the properties file so we already loaded this file by using p here so p is representing the property file so now we can simply say p do get property of and uh which property you want to capture app URL one or app URL 2 currently I'm using

Speaker A

App URL 2 that variable I can specify so whichever variable you specify here in the double codes 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

Speaker A

use from properties file simply use this command p. get property of username p. get property of password P do get property of customer URL like like this so whichever properties you specified in the properties file you can get everything by using p. get property okay so now we have replaced

Speaker A

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 config properties file

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

framework then we have added cross browser and parallel testing to the framework then also we have added config do 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

Speaker A

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

Speaker A

how we can do the data driven test case how we can add data driven test case and then how we can add 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 practice

Speaker A

also you do the same order so don't jump here and there first don't do cross browser and then don't do this log for so whichever sequence I mentioned here if you go to the same sequence if you follow

Speaker A

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

Speaker A

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

Speaker A

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 UND desired browser I will add another folder and folder wise upload in the Google Drive okay you can get get it from there and also I will upload this document today

Speaker A

you can get it there all right so let us stop here for today's session just complete these steps second third and fourth 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

Speaker A

the fifth step okay that's it for today's session I will stop I have taken lot and tomorrow we cont

Topics:SeleniumJavaHybrid FrameworkLoggingLog LevelsAutomation TestingTest LogsDebuggingApplication LogsCross Browser Testing

Frequently Asked Questions

What are the main types of logs discussed in the video?

The video discusses two main types of logs: application logs, which track user actions on the application backend, and automation logs, which record events during automated test execution.

Why is it important to generate log files in automation testing?

Log files help track test execution details, assist developers in analyzing defects that may not be reproducible in all environments, and provide a permanent record for debugging and security monitoring.

What are the different log levels and how do they affect logging?

The log levels include Trace, Debug, Info, Warning, Error, Fatal, Off, and All. Setting a log level controls which types of logs are recorded, with higher levels including all lower-level logs, enabling tailored detail in the logs.

Get More with the Söz AI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

App Store Google Play

Or transcribe another YouTube video here →