Course Syllabus and Prerequisites
Welcome to logging for Selenium test automation.
First, I want to introduce you to the syllabus so that you can understand all of the topics that are going to be covered over the next several videos.
These aren’t really sections per se that we’re gonna be tackling but they’re just more organizational units so for you to kind of have an idea of the topics that are gonna be covered and within these topics there may be one or several videos that cover each of these topics.
So we’re gonna begin by understanding the prerequisites so that you know exactly what you need in order to be able to proceed with the rest of this course.
After the prerequisites, I’m gonna tell you about the course resources and where to get all the course resources.
Next, I’m gonna tell you the advantages of doing logging in general.
Afterward, I’m gonna introduce you to NLog which is a specific type of logging framework that we’re gonna be using for doing logging within test automation.
Afterward, I’m gonna introduce you to how to install NLog and then we’re gonna learn how to configure NLog in the NLog.config file.
Afterward, you’ll learn how to make the logs actually work and perform their actual operations that they’re supposed to do.
And then finally we’ll finish up with a final exam, it will be both a video exam where I’m gonna test your skills and a written exam all to make sure that you actually cement all of the knowledge.
So, there are some prerequisites to this course.
There are several different software that you need in order to work with this course. So, the software’s you can see are on the left-hand side and then the my versions that I have and a short link that I specifically created for you to be able to access the resources is there on the right-hand side of the table.
So you’ll need Visual Studio IDE. I have 2017. That doesn’t mean you can only use 2017. It means that’s what I have and that’s where it works. And when you’re watching the videos that those are all the versions of working code and that’s how I get it to work.
However, you may use other versions of course but I can’t guarantee that everything is going to work for you the same.
And if you want to download Visual Studio, the short link is right there. All the short links are case-sensitive but they’re short so that they’re easy for you to remember
Next, you’ll need a Chrome browser. If you want to execute the solution that we have, you’ll need to be able to run the tests using Chrome browser. You’ll need a Chrome driver.
My version is 2.29.
Again, you may use the latest as long as it’s compatible with your Chrome browser.
You’ll also need Selenium webdriver which I have for the solution. So of course, you can just download the solution and follow along but if you want to create your own solution along the way then you’ll need Selenium webdriver. My version is 188.8.131.52.
And finally, you’ll need C# knowledge because I’m not gonna be teaching any C# here you basically already need to know and understand it and that you’re just trying to improve your skills by to be able to log.
Why is logging important?
Let’s jump into a little bit of the theory and talk about why is logging actually important when it comes to functional test automation.
Well, first logging provides us an actual written record of what happened after test execution.
Have you ever been in a scenario where you have a nightly test execution run or even a daily test execution run that maybe takes an hour or a couple of hours?
When you come back at the end of those couple of hours, right, I assume that you’re not there watching that test automation run.
So, when you come back and you see failures or even passes you want to see a record of actually what happened in your test automation during those couple hours or maybe while you’re sleeping?
And so, logging will allow us to do that because it’ll leave a record of all the steps that we performed as we were executing our functional tests.
Logging, when done well can actually make debugging of code easier. A lot of testing automation engineers are into the practice of when a test fails, they rerun the test which is actually the wrong thing to do because you might actually be covering up a real failure, a something important that needs to be understood and fixed.
Maybe rerunning the test is the right solution sometimes but it is not the right solution all the time and therefore those times when it’s not the right solution, you might be covering up real issues and so logging allows us to debug easier.
When we have good logging, we can actually use the log in order to retrace our steps and figure out what went wrong in our test automation as opposed to just having to rerun the entire test.
And with that, also, logging can make debugging faster because we have logs. We may just be able to look at the actual log file and understand the steps that occurred in the from the log and what resulted in the test failure as opposed to actually rerunning the test and you know seeing it fail which can obviously rerunning the test can take multiple minutes sometimes, right depending on your test and so, and you might have to throw some breakpoints in there.
Now you have to start debugging and stepping through stuff stepping into stuff and you don’t need to do that if you have good logs.
Introduction to NLog
So now that you understand why logging is important for us, I want to tell you about the framework that we will be using. In order to do our logging that framework is known as NLog.
So you might be asking why NLog? Right.
There are many different logging frameworks out there. Why is this the one that we’re going to use?
Well, NLog has three distinct advantages.
First, of all, it’s open source and free. So that means that it’s available for us to use without any cost. And it’s really easy to just plug it into your test automation without any hassles. No need for any budget approvals or anything like that and just plug it in and use it and you’re set.
Next, NLog has great online support. If you take a look at this image over here, you can see that NLog has many people watching the source code.
It’s been starred thousands of times and it has many different forks which means that it has great online support. You will be able to find solutions to your problems really easily.
The documentation is fantastic and you’ll have no problems doing whatever you need to do when it comes to actually using someone else’s framework.
And finally, why we’re using it is because it’s an active project. If you look at this image in the center, what you can see are all of the commits over time and as you can see that commits have been happening for multiple months.
They’re happening every week and that means that NLog is constantly growing and improving.
It’s an active project that’s likely not going to die. It in fact, it’s probably getting bigger and expanding more and therefore you know, you’re picking a reliable framework to tie into your test automation.
So overall, that’s why we’re picking NLog. It’s free, great online support, it’s very active, it works well that you don’t need to explore any other options and so that’s why we’re going to work with NLog.
Now that you know that we’re gonna work with NLog, let’s talk about the different logging levels that are available for us in NLog.
First, we have the trace level.
Trace levels are basically very detailed logs. These are as detailed logs as they get.
They don’t get much more detailed than that. The way you perform a trace log as you do logger dot trace. Whatever your logger object is and then you do that trace and then you place, your message in there.
Some examples of great tracing sections may be when you’re trying to identify an element and if you want to log its locator right like maybe it’s XPath or something else and you can log that message to say that I was looking for this element with this identifier that’s deep detailed trace logs can be used there.
The next level is the debugging level.
Debugging is just less detailed than trace still typically not enabled in production environment and debugging is you perform it by doing a logger dot debug and then supplying your message some good areas for debugging, debugging levels can be something less detailed than a trace message.
So maybe instead of actually logging the entire XPath of the element, maybe you can say that you’re trying to click some specific button or maybe you can say that you’ve entered into a method something like that.
The informational logging is performed by doing logger that info and supplying a message.
So you can see how everything is so simple but anyways informational messages are normally enabled in production. And for us, with functional test automation, we’re actually going to use it for our bug logger and of course, I’ll teach you about that later but what that basically means is that we’re using the info logging to represent our manual test steps.
The warn logger level, you can perform using logger dot warn and these are warning messages typically for non-critical issues which can be recovered from. So may be a good scenario of that is, if you’re doing some kind of an if statement. And you’re trying to perform some operation and you have an else clause there and so your if statement fails, and then it falls into the else clause that is not really critical, but it’s not good that it happened right.
Maybe you’re trying to click on one button but then that button wasn’t there. And so you have to click on a different button so maybe you do a log dot warnt here so that you let yourself know in your log that, hey there was a little weirdness going on here. Nothing critical but just something happened.
Now, whenever something more critical happens that’s where you can start doing logger. Logger dot error and supply your message error messages are most of the time.
Just exceptions right so any time you’re having try cashbox and you’re doing your catch, you’re catching an exception that from there you might do a logger dot error. And then just display your exception. A lot of times you can display the message of the exception. The stack trace of the exception and the inner exception of that exception object.
And finally the most critical of all is the fatal level.
You perform a fatal log by doing logger not fatal and supplying your message. These are very serious errors usually indicating the shutdown of your code. So an example of that may be, let’s say you’re looking for a chrome driver and your chrome driver binary was not found.
And so there you might try to create a new driver. And then the path was not found, then you might throw up a fatal exception saying that I couldn’t find chromedriver hence, your test can’t start. Hence, your whole framework needs to shut down that. That’s an example of a fatal.
Well anyways, so with all that said, now you know which logging framework we’re gonna use, you know why we’re gonna use it, you know the differnet logging levels available to us, let’s go ahead and actually jump into the fun and start coding setting everything up and learning more about how to use NLog.
How to Install NLog
So let’s go ahead and get started with the fun of installing and configuring NLog.
Now I do want to give you a word of caution. In this tutorial, I’m gonna teach you enough to get started with NLog. I’m not going to dig into all of the details. NLog is extremely configurable. It has tons of different configurations that you can do.
However, I’m only going to give you enough to get you started and functioning normally. I honestly don’t think that you need any more than I’m gonna teach you here.
Of course, there are different scenarios, maybe you may need more than I’m teaching here. And I would leave that for you to explore on your own. However, I’m gonna teach you enough to get you started and working. And I think for the majority of the individuals doing test automation, it’s gonna be perfect and you won’t ever need to touch it again. You might need to tweak a few configurations here and there based on your needs.
But other than that everything that I’m gonna show you here will be enough. I myself actually have not spent too much time learning NLog. Maybe I’ve spent about five hours through my entire career actually, reading the documentation and then of course you know a couple hours using it here and there, but other than that I just kind of learn as I need and at some point when I set up all the configuration files.
After that there’s very little that I need to update and so I believe that you’re gonna be in the same boat, so just remember that. I hope you’re not expecting a comprehensive coverage of NLog. Because first, I don’t think it’s necessary and it will be probably a waste of your time.
And second, I think this will be just enough just the right amount the biggest bang for your buck to get you started.
So anyways, with all that said let’s go ahead and get started.
So I’ve got my solution open here, and what I’ve done is actually copied over this sample app project that has a bunch of automation page objects and tests. And I just copied it over into what I’m calling a logging practice project.So it has all the same classes in here which we can now use to practice logging with our test automation.
So the very first thing that we need to do is install a Nugit package
So to do that, it’s very simple we’re gonna come here manage and you get packages and then we’re gonna go to browse and search for NLog. And we’re gonna get NLog that comes up, and so what you want is this very first one.
And I believe that this package installs NLog which with included core logging functionality for your main project. Also, need to install NLog configuration packages.
So let’s install this.
Excellent, let me see if we need to install anything else, so yeah that didn’t pull down what we needed. So we also will need this NLog.config which will install the appropriate configuration files that we need.
Excellent, and so with that, we have our NLog.config and NLog.xsd files which are exactly what we need to get started. So these two Nugit packages and log in and log that config and those are all you need to install.
And keep in mind, this is my version here right now. Of course you can, you should be using the latest stable version of NLog. It may be different, no big deal 99% of everything I say here will apply and it rarely changes. I haven’t seen a change over the years for n log and I don’t think there should be many changes happening that will affect anything that you see here today.
Starting to Log
So as I mentioned, there are two important files for NLog. There is the NLog.config and there’s NLog.xsd. XSD basically the definitions that tell the n log dot config how to behave the XSD is not really important and I never really even learn too much about it.
And I don’t think you need to waste your time learning it either. The NLog.config is gonna be really important for us. And we’ll get more into it in a few minutes, but first I wanted to take you into the actual logging that’s going to happen inside of our page objects.
So here, I’ve opened our home page and in order for us to be able to log we need to create a logger object for every single class. So to instantiate a log object, you use this exact statement right here and our log manager from our NLog Nugit package will get the current class logger. Meaning that it will log as the home page and that will be outputted into the message.
You’ll see exactly what I mean in a few minutes but basically you put this statement into every single class and then that logger will have the appropriate information for that class.
And don’t forget to pull down the appropriate using statement because you’ll need it for your logger class.
Now the other thing I’m gonna say is that your logger should not penetrate into your actual functional tests. The logger should live in your page objects when it comes to functional test automation. It may be different for other applications but in terms of functional test automation you should keep your logging objects inside over your page objects.
So now if we want it to log, we can use the logger anywhere here that we want. Let me show you an example. So we can take the longer here and after we go to the URL, we can use the logger to log info that we opened a URL and that URL is this URL that I’ve extracted out into a variable to not have duplication.
And so what this is going to do is log at the info level that we have opened a URL. We can do another logging over here. Another message here.
Let’s talk about what we did here for a second.
Why Info Level is Important?
So we only logged using the info logging level. However, if we open up the longer object you will see that you have many options and these are the options that we’ve discussed. You can do log that debug, log that error you can do you know fatal of course whenever your application crashes, you can do info and warnings and those are basically all of the logging configurations that you need are available here and you can apply them as appropriate.
Remember the definitions as mentioned previously, what I did want to specifically talk about is logger.info because when it comes to test automation I use longer dot info to signify manual functional steps that we are performing for our test.
So that whenever logger.info is happening we can actually use these steps to recreate a bug for example. And they are actual manual steps that we would perform to do an actual test.
So for example, if we are performing this test when we do the go to message. We are going to login for that you open URL and that URL is logged then if we search for something there’s gonna be an info log that says that we search for an item in the search bar and that item is specified.
So what’s gonna happen is in the log you’re gonna see information that’s info. And you can use that for your logging bugs or anything else. So keep that in mind log.info in terms of test automation should be used for logging manual steps.
If you wanted to do more extensive logging, of course, you can do that. You can come here and do logger.trace and of course you can start logging stuff like this where you found an element by this ID and you send these keys to it and then you found an element by this ID and send keys to it as well.
You can do that if you want, but logger.info is really important to almost every functional method so that you get functional steps out of your tests. So that later you can use them to derive manual test steps.
So now that we even got the longer setup you might be asking. Well, aware is the logging actually gonna go and that’s a fantastic question, that’s where our NLog.config comes in handy.
So here is the NLog.config up here at the top. You can see some information about the XML stuff you can also see that NLog has some default configurations for the actual NLog.
So in this case you can see that whenever NLog encounters issues, here it’s a throw exception is set to false which means that you know NLog if it’s trying to log and it gets an exception it’s not going to break your application and that’s actually what you want it to be set to because you don’t want NLog interfering. You don’t want logging breaking, you know problems in logging breaking your application, they’ll be silly because that really has nothing to do with your application. You’re just using the logging to help you debug the application.
So that’s sort of false and you can see that there’s a log file and that goes to this destination as soon as we start logging. You will see that here at this location there will be a log file, if there are theres.
Let me actually show you my system if I go here at C temp, you can see that there is an NLog.internal and I actually believe that this is from my other applications. We can open it up and see what that looks like and this is if NLog gets this is logging for NLog specifically not for your application. And you can see that this is what it looks like for NLog if there are any kinds of errors, you will see them because a lot of times they will look really big like this.
And so you can see that there was an error initializing some event. In fact it was an unable to initialize event log and there’s a bunch of information in here that you can use to debug.
If for whatever reason your logging is not working that’s the NLog internal log, so don’t you don’t need to modify anything. In that file up here just keep it standard unless you really have a need to modify it but I recommend don’t waste your time modifying things that are already working.
So the next section is this variable section. The variable section will allow us to use some variables and their values throughout NLog. And I’ll show you a little bit about that later.
Next, we have the targets section. The target section tells us where the logging should occur and how that logging should occur. So in order for us to do any kinds of logging, we will need some code in here that will allow us to log to a target.
And there’s also you can see that a bunch of documentation here that you can take a look at from NLog, it’s very useful. If you want to know all of the targets and how to modify all the targets it’s all there.
But you get started, what you can do is paste in this code right here and whenever we’re actually done with this you’re gonna have the perfect log file to use for your test automation.
So you won’t even need to touch anything, you’ll literally just need to copy over the Nlog that configuring to your NLog.config and you’re gonna be all set. You won’t need anything else but for now you can just see how we set things up.
So I’ve added a target here. You can see that the target is here and the opening and closing braces for the XML are there, so this defines the target of where we’re gonna log the target needs a type.
So the type is actually can be told to you by the XSD, so if you open this up, you can see that there are different types here that can tell that can help you so you can log to a database. You can log to a file, you can log to mail, you can log to memory, network.
There are many different places that you can log. However, we’re gonna log to a file, there is a name attribute that tells you the name of the targets. This is something that we will use throughout our NLog.config file and we’ll refer to this target by the name called default.
There’s also a layout. The layout is very modifiable and you can see the layouts over here for all the layout renderers at this documentation and I can explain you our how our layout, what our layout does here.
Layout in NLog
So the layout defines to us how the long message is actually going to look in our output type.
So, in this case, we’re outputting to a file, so this is how it’s going to look in this file. So if you look at this string you can see that it is pretty long but besides being pretty long you can see that it actually kind of resembles C# syntax.
And you might guess that there are some variables here that are being filled in. Of course you can get all the variables at this documentation here so that you can better understand whatever variables you want to use, but again I’m pretty certain that you won’t need to modify this and lock that config file because I’ve already configured everything for you.
To do test automation with so, it should be good unless you have some really specific needs but I just do. I will explain it to you just so you understand. Regardless, so this output is we’re gonna get a long date which is just a date in a long format.
It’s gonna output the thread ID so when you’re running your test on parallel it’s gonna put the thread ID. There it’s also going to output the class name and it’s not going to output the file name. It is not going to include the source path and it is going to include the method name.
Again, got all of this just from the end log documentation it’s going to log the level and that the level of logging is going to be uppercase. It’s going to display the message so this is the message that you provide when you’re actually writing out using NLog.
Using NLog so for example, here’s our message, here this is the message that we supply, here’s our message there this guy right here tells NLog what to do on exception and we are outputting our exception and outputting it as a string, so I know that’s a lot but again it will once you see it I think you’ll long better understand exactly what’s happening.
fieName and keepFileOpen in NLog
The other two attributes to note here are the file name. The file name is really simple it just basically says where do you want to log.
And here it says that we’re gonna log to see temp application name which is a variable that we need to define and then it’s called and then into a file called debug.log.
And so that brings about a question where do we get this variable name? Well, that’s why we have this variables section. So let’s go ahead and take this variable and say that it has an app name, its name is app name. And then let’s give it a value and call it logging practice.
So I’m calling it the same as our project. You can call it whatever you want. Of course, I’m calling it the same as the project name so that’s where it’s going to log. And then finally keep file open will tell you whether you want to keep a file open.
Instead of closing it on each log event, keeping a file open will obviously not allow multiple threads to access it at the same time. Well if you close it, then you can log to it with multiple operations. So that’s really it that for the targets.
So now with this said, this will allow us to log into a file. All we have left is to set up a rule that will allow us to log.
Creating the First Log Records
So this section with the rules you can think about it as rules for how we’re gonna use our logs to actually log. Let me better explain it with an example. So I’m gonna paste in this rule right here, again you probably don’t need to modify it and at the end of this, you’ll probably just take this file, just use it.
You’ll understand the logging and you’ll understand n log and you’ll be done with it. But either way, I will explain it. So this rule here and this is a standard format and of course, you can have multiple properties and values.
However, this is the minimum so what this rule right here says is that we’re gonna have a logger that logs from all the all the different types of classes and packages and projects and namespaces, so there’s gonna log from everywhere.
If you want to filter it, you can, you can, for example, say I want to log only from element interactions or something like that but here this says that we’re gonna log from everywhere. That’s where the star is we’re gonna output to our default target.
Here is our default target, so using all this and then the minimum level of logging that’s going to occur is going to be debugged so if something is trace for example, that will not get logged but debug and above which is like info warned error and fatal.
All of that will get logged into our default logger.
Does that make sense?
If not, no big deal because now we are ready to test our logger and you’ll see the output from it, so let me go ahead and do that.
I’m gonna come here to the test explorer. Actually, let me go back here to home page and I’m just gonna right click here and do a run tests. And so now oh I’m not in the test, I’m actually of course and they were building errors.
All right errors fixed got the test open. Let’s go ahead and run it. Okay. Awesome, it’s going we’ve got our chrome window here. Which that’s not really important. Let it do the test, that’s fine what’s really important is to look here in our temp file.
So check it out. This logging practice folder was just created at 7:25 2017 5:45 p.m. and that is the exact time right now. As you can see, this was just created and if we go inside we have a file called debug.
So, so check out this path here. See temp logging practice and then debug and I’m gonna take this and I’m gonna pull up Visual Studio again so that you can see our analog config side-by-side.
So check it out. Remember our filename here is our current file name.
Check it out, see that how it replaced our app name with our happening here. And of course, we’re logging to debug.log I just did not append that to the file path.
So that’s how that gets created and if we open it up you can see that as expected, we have to logging messages of course both of them are info and you can see that here is our long date. Here’s our thread ID. Here is our namespace.class.method and the namespaces are wrong, simply because it wasn’t changed when I copied over the project I’ll need to update that namespace. It should be logging practice namespace but it has that information and then it has the logging, logging information and then your message.
So how awesome is that you can see that we actually have some logging happening and it was very easy to do so.
More Information About Info Logging
So that’s really all there is to logging. There is a lot more custom customizations that I’m going to teach you, to make it perfect for test automation so that you don’t have to really do any work.
We’ll get to that in a second but if you didn’t want to add more targets, you know how to do that now. You just copy these. You just add more nodes here, more target nodes. And make sure that you supply all of the relevant information, such as the type and the name and the layout.
And if you want to add more rules you just add more nodes here as well. Just add another node here and then so on and so forth. And you can have many different rules writing to many different locations.
And from whatever classes you want, it doesn’t matter the only other thing that I want to mention is we already talked about the info logging so keep the info logging for your functional test automation so that you are able to reproduce the steps manually.
If your log is looking good a lot of times you’ll be able to reuse this kind of information to just take it and paste it into something like a bug report. All right, you can take this step copy and paste take that step copy and paste and so on and so forth.
For the rest of your info steps to reproduce a manual test gate because a lot of times developers will want steps to reproduce a bug so you can put that in there or it’s useful for anybody that wants to reproduce the bug that your automated functional test has found, so don’t forget that part.
And a lot of times, it’s also very used for almost every functional method to have an info step, you have two options and it depends on how you want to do it. You can put a info logging step before the method starts.
Maybe I would recommend there you do something like a debug or trace where it will tell you that you have entered a certain method so for example, here maybe we can do something like logger.trace and actually trace. Yeah, we can do trace and then that will say here.
So if we enter into this method, the first thing that’s gonna happen is it’s gonna get logged that we’re attempting to perform a trace, so you’ll know that you’ve entered this method and if anything goes wrong in here, first of all the logger will spit out all the information, all of the errors for you and but you’ll have this reference knowing that you entered the search method but after that, all the steps have failed.
And then we kind of have this info step after all of the actions have occurred, kind of li implying that the step has passed right because if any of this failed, we would never really get to this step and so this would never get logged.
But because these two steps have succeeded, we can now log step 28 and know that that step has succeeded and therefore it’s kind of a manual stop telling the individual what to do. So that’s kind of very useful for you. Just play around with it.
I don’t recommend that you automatically just start throwing traces and infos everywhere but I do recommend that you run your tests and attempt to look at your logs to make sure that they look good especially your info logs. And that they can easily reproduce for you all of the manual steps to reproduce a test case.
And once you do, do the logging and clean up the logging a bit. It’s all just trial and error and kind of just cleaning it up here cleaning it up there as you proceed through the automation it will be good and then you won’t need to come back and edit it again because once I’ve entered it into the search method, now my search method is set and any time I’m performing a search. It’s going to have the appropriate logging to go with it.
So that’s something specific to functional test automation but it’s something that will be very useful for you whenever you’re trying to debug your tests because you’ll be able to debug them from the logs rather than actually re-running your test automation.
So by now, I am sure that you are an expert. No, not really, you probably still have a little bit to learn but regardless I am going to give you a NLog exam. Which I just realized I didn’t name right here NLog exam, this is kind of an open book exam where you’re going to use the analog documentation in order to give me the answers to the questions that I am going to ask you right now.
So feel free to browse the documentation here and here and more. If you need of course you can use Google as well but try to do these exercises on your own so that you get that deliberate practicing and can actually understand how to do this. But you are allowed to use those resources and just try to finish the exercises and do your best.
And then when you come back, I will give you the answer. So here’s what I need you to do, it’s a multi-level exercise. There are many different steps to it.
So first thing you need to do is, create multiple different types of loggers for me. I want an event log, meaning that it logs to the event log of the system. The source of the event log is going to be the application name, the filename is not applicable.
The logging rule will be that you log from everywhere error and above. The layout- you can do whatever you want. I also need a debugger log. The source is not applicable and the file name is not applicable.
However, the logging rule will be that you log from anywhere from everywhere debug and above. Layout can be whatever you want and then I need a third type of log. This is this log will log to a file, the source is not applicable, the filename should go to this location. See temp then replace that with the app name, call it bug logger underscore and place a short date in there dot txt so that’s gonna be the file name.
The logging rule is that you’re going to log only from logon practice namespace and log only info. And above and I did realize that I misspelled the entire project name was supposed to be logging practice but it’s already named log in practice.
So whatever, but just use this namespace. And just to clarify one thing was that when I copied over all of the files from this project the namespace for all of the files was incorrect, it was sample app too so I actually did use ReSharper in order to move all the files to the appropriate namespace.
Let me show you what I mean by that.
So here is an example of that as you can see what I did have I moved everything over to the correct namespaces now. So if I open up my solution and browse the log in practice I can look anywhere here and it will have the appropriate namespaces.
Before to sample app two and I had to use ReSharper because ReSharper provides a really handy easy way to do it and so I updated that. So previously it was the wrong namespace.
Now I updated it to the right namespace and so, therefore, that’s what I’m saying that for this logging rule I only want to log from that project login practice. I want logs from nowhere else but this one and info and above. So that’s what that means and the layout I want only the message.
Okay, so those are the three different types of loggers that I want you to create and then there’s one more modification that I need from you to our and log.config. So what you’re gonna do is you’re going to set up archiving of the default law.
We already talked about the default logger that’s its name just a little hint.
Now you’re gonna give the archiving a file name, can be whatever you want, just has to it has to be a name and has to be working. Give it an archive numbering again what with a little research you’ll understand what that means. You need to archive every month.
And finally, you need to set a maximum archive files number, so again with a little research, you’ll know what all of that means and you should be able to pretty easily find it and set it up yourself. So that is the NLog exam.
So take some time, look at the docs attempt to answer all of these questions and then when you come back I’m gonna give you the answer. And also afterwards, there’s gonna be a written exam but I wanted a video exam so that we can do everything live and interactive.
Okay. See you in a bit.
NLog Exam Answer
So hopefully you were able to figure all of that out. It was a, I think a pretty fun exercise. It’s very exploratory just a matter of trial and experimentation. So as long as you follow the documents and my questions and everything works. You’re basically good to go.
So I’m gonna tackle these one at a time from top to bottom in no specific order but they’ll correspond to an actual question so over here at the top in my NLog.config you can see that I’ve set up the archive section. That is right here.
So the archive section you can see, that I provided a file name using the directory that I asked for with the app name and the short date so this is the format that you should have something very close.
The archived numbering I’m just set to a sequence I didn’t I, didn’t tell you what to set but you could have said anything you want.
I’m setting it to sequence archiving every single month and you were asked to set. And a max archive files – set to 30, yours could have been anything.
Let’s take a look at the next section.
So the next section here we’ve got the event log, the event log is of type event log. So you needed this part, you could have given it any name that you want. I named it event log the source. This was the other part you needed to supply the source, so the source of the app name.
And then layout, you could have had any layout that you wanted. This is my layout so this obviously logs to the event log, whenever a certain rule happens which will check in a second. So if I scroll down here, now we have the debugger.
The debugger you can see it’s configured right here, so it’s over type debugger. I named it a debugger and then the layout is just the message. Finally we have our bug logger so you can see that I started by giving it a name. I’m calling it a bug logger.
It’s, it’s a type called file, so because it’s gonna be writing out to the file and then here is the path that I requested from you and then the final layout is just a message and I’ll show you why I did this and why it was important.
And so now to the rules section, here are all the rules that you should have had the default we already had set up. You know previous exercises, the event log, I asked you to log from everything which means the name is star and the minimum level should have been error.
And above then the debugger we are logging mean level info so that it’s info and everything above and finally we have the bug logger which will log from our namespace log. In practice.star, meaning from any file in this namespace because I don’t want to log from anywhere else.
It’s gonna write to the bug logger settings minimum level of info, so those are all of the configurations that are set up in our NLog that config and if you are passed this exam.
Congratulations you did a very good job.
Now, let me just remove this guy here because it’s not really necessary for anything. It was just for a purpose of exercise and now with that removed. This is actually going to be our final NLog.config file that you simply need.
So really even though now you do understand the NLog and you understand logging and how to set everything up, really now if you just download the solution off a GitHub, you’ll be good to go just simply by taking pulling down this NLog.config and sticking it inside of your automation framework.
And then you’ll basically be good to go. Of course, as long as your namespace here is correct, so that’s that. Let’s go ahead and run it so that you can actually see the results of everything here.
NLog Bug Logger
So let me pull up my test explorer. I actually ended up creating a new category called logging so that we can more easily run our tests.
So here I have a category logging, I’m right click this test and I’m going to run it. So give it a second to execute. It’s executing on my other screen and while it’s finishing running, what I’m gonna do is pull up my C C temp and inside of town you can see I have a logging practice folder.
And so inside of that, I have my bug logger and I have my debug and the bug logger. Let me show you that, I think it’s really cool what’s in here if I open it up, you can see that my bug logger this is what it looks like right here. And so this bug logger is actually really useful.
This is what I talked about before where you’re gonna want to use the info logging level in order to log your steps. Well, now you can see that my info steps are being logged that to here without anything else.
I’m not getting any of that other information. Remember, for example like here if you look here you see all of this other information that’s cool and great for us to debug but it’s not used for useful for us to log bugs.
So, therefore, what you can see is now I have like test steps here that I can just take. Copy these, page them into a bug report or any other reporting that I need for the test steps and now I have actual test steps here to peruse.
So that’s why it’s awesome. So we automatically get this just by simply configuring our and logged out config and so now we have a bug logger. It’s gonna log here all the steps and then you can use those for whatever purposes you need.
If you need a way to recreate, so that’s the cool thing about that info logging that I told you about.
So that’s it.
That’s the exam hope you enjoy it and hope you did well. If not, you just go ahead and review everything so that you’re ready to proceed to the final exam, the written final exam.