 Okay, welcome to lecture 20. We're now getting into the final block of this course And today we'll talk about server-side testing and debugging. We'll get started with that and then we start and we continue lecture 21 with a second part on it So what we'll do first is we talk about linting of JavaScript and Node.js JavaScript, so that's basically trying to do static analysis on JavaScript code Then we go into debugging node. We have already done a regular debugging of JavaScript applications in the browser Now we'll transfer that to nodes and then we do the same with unit testing So we have done unit testing in the browser We'll now do unit testing for node.js and then finally we talk about a concept that's called stubbing or mocking Which is an important concept in unit testing. It applies both to the browser and to node.js There are all sorts of learning outcomes. They all go down to testing server-side applications So that's what we'll talk about mainly today And there will be different parts to that The the literature references are essentially Connections to tools so ESLint is probably the most popular linting tool for JavaScript knock and sign-in are tools for doing mocking stubbing which we'll talk about later and Then there are two how-tos on how to debug Node.js code. So that's just for reference So this is something that I have mentioned in lecture 9 already. It's a bit of a repetition, but Quality assurance on a large scale is not just about testing Tests automated tests are absolutely needed and they give you a quick feedback on if a bug develops But you need other things and one of the things is a debugger because it's much much easier than placing console logs in your code So that's something we do and then another thing that helps you to even avoid mistakes before you get there is To use a linter So you can in you can enable strict mode that prevents you from doing certain things in JavaScript You can try to follow style guidelines how to structure your code, but then there is a linter and those are tools that Check your code So a lot of errors we know that can be avoided when the code is written properly So when you write messy code if you have kind of different Different way of writing code different places then this leads to errors Not only because you miss things but also because you might go back to your code a bit later Or someone else tries to modify it And then if it's not very easy to read and it doesn't follow any style then there will be errors so Linter's are tools that help by analyzing your code. They just look at the code. They don't run it and then they highlight issues They can be used To highlight common problems that lead to errors, but they're also used to enforce style standards So for example companies use them to enforce that you follow a certain indentation standard or a certain variable naming standard These tools exist for almost all programming languages. We look at JavaScript here, of course In JavaScript, we will use ESLint, which is as I said one of the biggest tools There are lots of options to configure this. I'm not very good at it But the good thing with ESLint is that you can actually install predefined styles for example from Google or from Facebook that They just use their style guidelines There is an integration to VS code if you install the ESLint plugin And there's integration with Node.js So you can install if you follow these steps you simply have a tool that Can statically check a JavaScript file So you can just run ESLint my file.js And then my file will be checked and you get a console output I'll quickly show you how this works in VS code because that's a good thing to have So let's just open a project For example the Minesweeper code so the code that actually is running For assignment 2 that is providing the back end functionality and It does use a bunch of different things. It does use a database. We don't go into that. It's not very important But we'll now show you how to run ESLint in here So given that you have actually installed the plugin so you have to install the ESLint extension Otherwise this will not work. I have done that so I can just go to Finding the right thing the command palette And then there is one point that is called create ESLint configuration Just click on that and then I get the terminal and it asks me different things So what I want to do for instance is check syntax find problems in force code style What type of modules do I use I use JavaScript Or common js I use common js Which framework do I use no framework? Where does your code run it runs in node and now you can basically answer questions you can Check automatically or you can use an existing style guide So I could for example go in and say please use the style guide that airbnb is using let's do that What format do you want your config file to be in? I don't really care JavaScript and now it starts doing stuff. It starts installing. Would you like to install? Yes, please So there's all sorts of installation with npm going on in the background all the the right tools are Being installed and then it creates a file in here Which should be visible in a moment, but There is a hidden file that is called ESLint RC Here that's basically our configuration. So how should we run this? And now if we go into fjs, you'll see all sorts of stuff my code is all red And that's all the problems that the lintre has found. So some of these if you scroll down some of these are warnings For example, we don't want anything on the console That's a common thing you want to use a specific tool for logging not just logging to the console But other things are actually errors For example airbnb in the airbnb style guideline They do not want me to use var. They instead want for example let And then that works then there's another problem here Express is never reinsights. So i'm i'm creating a variable that I can change but i'm never changing it So I should use const instead So you already see that there are quite some things that they're not necessarily errors, but they can lead to errors So it simply highlights those things and then there's other things like here's the indentation Airbnb has a standard of using double space indentation here. I have four So if I instead do two spaces it stops complaining. So this is really more a style thing What you have seen before is more a potential source of error And then airbnb uses single quote styles. So I should use Single quote not double quote and i'm unable to find my quote Here and now it stops complaining. So these kind of things are what a linter does it helps you to To find problems in your code and fix them so That's essentially what it does and this is very common at companies simply to avoid errors and to enforce a certain standard style now if I Want to get rid of this in in vs code. You simply delete this file And now if I reopen this directory then the the warnings and the problems will disappear so If I reopen the file you see now it's all gone So that's what we want to use a linter for it's a good idea to try this out and get used to it Also, if you for example do your prior your final projects Try to use these things so that you get a common style of writing code In the beginning these things are often A pain in the butt in the butt basically So you need to get used to them But after a while you get quite used to them and then you simply have a Very common style if you code with a bunch of people or an entire company and that's of course a good thing As I said ES lint allows you to have these reusable styles. So You can simply go to the ES lint website and check that out what kind of rules you can set So that's the part on linting now, we'll jump into the debugger We have done Debugging in the browser. So you have seen that before we had a we had Let's find something For example in One of the early assignments Was it lab three? Yeah in lab three there was this task to To run certain things and there is already Testing going on here automatically. So I cannot do much but I could go in here and I could go into the debugger and actually Debug my javascript file. So I could set different break points And then run the debugger. So if I Print my number, I would end up in the debugger and I could Look at the call stack. I could look at the scope different variables. So we did this Now, of course, we have the problem that we are in node js So we're not longer running anything through the browser. So of course, we cannot debug through the browser. That doesn't work So this is why we'll have to look at how do we run the debugger in node js The Principle is exactly the same. So we can use for example the vs code debugger. It looks exactly the same It's just about how to connect to it And what node allows you to do is it allows you to run A piece of software in debug mode. So you simply add this inspect flag Instead of just running node app js you run it with minus minus inspect And then what happens in the background is that there is a specific port reserved for debugging. So you can connect to that With any kind of debugger I'll show you two here. We can look we can use chrome for that. We can use vs code Both is fine So we'll look at exactly the same things we also did for the browser an important thing here is This is one of the issues that's mentioned in the owasp top 10 and the security issues Please never leave the debugger open when you're in production because people can connect to it. They can Read all the details of your code. They can look at different things. So that's uh quite a severe thing So be sure you only run this in a protected environment Or for a kind of specific points in time when you need to check something Okay, so let's try a server. Um This is the the mind sweeper thing. We can just run that So Let's go into that I need a database So I need to run my mongo database That's just a tool. It doesn't matter if I would use anything that doesn't have a database. That would also be fine So before that I was running the application with node app js Then it starts Now if I want to have a debugger, I simply add minus minus inspect Now you see there is some more debugger listening, uh, blah blah blah Now the code is running. I can use it. So I can uh, I can just go to my my browser and do localhost 3000 mind sweeper generator. So it does work as usual That's the important thing Now If I want to connect the debugger, I need to use a debugging tool for example chrome That's open google chrome and I just go to chrome colon double slash inspect And if I do that I should get Something here So it automatically found that there is something that has a debug port and then I just do inspect And then I'm here in my inspection mode. I have already started doing things here. So that's why you see something But you see this looks familiar. There is the debugger up here is the call stack We can look at different things If you do not see any code here on the left side So if you cannot select any files, you might first have to add folder So you might first select the right folder and and open it. That's what I did here um now The important thing is now that we can do exactly as we did before for example, we can go into any of my Routes so this might look familiar to you. It's it's programmed slightly different But this is the code that gets called if I do slash rules So I can for example set a breakpoint here And now if we go back into our firefox for instance, uh, if I just run the regular code If I go to slash everything is fine if I go to slash rules You see that it starts loading here in firefox. Nothing is happening And in chrome you actually see that it has paused we are in our debugger and now it's exactly the same as before So we have our call stack We have the scope we can look at the variables we can for example look at what is in the request What is the ip address that has sent this? It's not very interesting here. What's the host name? So the request came from local host And then we can look at the headers for example So these are the HTTP headers So we can look at that and then uh as before we can sort of jump to the next step here We can go into a function call. We can do different things and when we're done. We can just say resume Uh, and now if we go back to firefox, you see that it has loaded hasn't been successful, but that's okay At least it has finished Executing the server has sent the reply So this is one way of doing it. Um The other way Is by running the code through vs code So you can also run the debugger here So what I could do is uh, I simply create a new launch configuration So I go to run add configuration and I say for example attach There are different ways of doing this, but I can say attach and then here I have the debug port So where do I want to connect? And now for this to work. I actually have to run my server With the inspect mode as before And now I can go to the debugger and I can select here my attach configuration and do start And you see that it has somehow connected through it Uh, and now I'm in my code here as before I can start setting break points I've done that here already just to give you an example Uh, so now if I go again to my rules and I press enter Instead of chrome I now end up in my vs code Uh, and if you then go to the debugging view again, you have exactly the same you can look at The variables you can look at the call stack And you can as always jump over do different things continue so That's another way of debugging. Uh, and then when you're done, you just close the application So those are the two things I'll I'll show you here And in assignment four you will have to use the debugger a bit just to get you used to that It's an important thing Just that you go in there to really use it in a productive way. You have to Keep using it for debugging. It's really a good help. So try it out Okay, that's the first part now the second part of the video will look into unit testing again