What is Automated Testing

Mosh Hamedani
A free video tutorial from Mosh Hamedani
Passionate Software Engineer and Best-selling Author
4.5 instructor rating • 20 courses • 506,754 students

Learn more from the full course

Testing Angular 4 (previously Angular 2) Apps with Jasmine

Learn to write unit and integration tests for your Angular apps and deploy them with confidence

02:10:00 of on-demand video • Updated April 2018

  • Write clean and maintainable tests for your Angular apps
  • Examine how much of your code is covered by tests
  • Write tests for re-usable components
  • Write tests for component templates
  • Write tests for forms
  • Write tests for confirmation boxes
  • Write tests for the navigation
  • Write tests for attribute directives
  • Work with asynchronous operations
  • Provide fake dependencies to components under test
  • Use spies to track function calls or replace functions
English [Auto] So what is automated testing. Is it a replacement for manual testing. Do I really need it. How should I do it. I actually write my tests first which we call test driven development. Or should I write the application code first. Marsh I don't know what to test. These are the questions that a lot of beginners do automated testing as well as developers who have some experience having their head. So let's start with the first one. What is automated testing automated testing is basically the practice of writing code to test our code and then run those tests in an automated fashion. So here's an example. Imagine we have this function somewhere in our application. It's a basic calculate function. It takes an input and depending on some conditions it returns different values. Now imagine this function is used somewhere in the application with manual testing. We have to launch the application and the browser. Perhaps we have to log in first maybe do a few clicks here and there to get to the target page then we have to enter values into a few form fields. So eventually this function is called. Now this is very time consuming this whole cycle to execute this function in a manual fashion may take 30 seconds of our time with automated testing. We can write code and directly call this function with different inputs and then we can run this code in an automated fashion. And this may take only a fraction of a second to test this function with different inputs. So with this practice we can test a large part of our application functionality and maybe the entire application in an automated fashion several times faster than a manual tester. Now here we've got this opinionated developer John Smith and he believes writing all these tests is time consuming because not only do we have to write the application code which we refer to as production code but we also have to write the test code so implementing a new feature retests will take significantly more time. As opposed to implementing it without tests because a part of our development time is spent on writing and maintaining these tests. So this is what John Smith argues. What you see really right or wrong. Well let's see. Let's say we don't have any automated tests as we add new features and our application grows in complexity the time required to test all the application functions with various arguments increases exponentially. If you have worked in a large application with a lot of features that have been built over years you know that sometimes no one in the team knows how these functions work and how they should be tested. Nobody knows the requirements because those developers were initially built those features are no longer part of the company. So there are a lot of legacy functions around and nobody dares to touchdown. Now if we implement automated testing we can test a large part of applications functionality using automated tests and the time required to do manual testing will be far less. In fact some companies do not have any manual testing at all. They automate everything. Now whether that's a good practice or not it's debatable. But irrespective of that some level of automated testing can definitely reduce the manual testing effort. But there's also one more benefit to automated testing with automated tests. You can catch the effects before releasing her Soffer and this can save you from a lot of nightmare. Have you ever been in a situation where you deploy the application to the production you were happy you went home and then 30 minutes later you got a call from your boss saying that a critical function application is not working. And then you have to log in remotely or go back to the office and spend several hours till very late at night trying to fix a bug. Most if not all developers have that kind of experience at some point in their career. Now with automated tests you catch more bugs before releasing your application into production. Now I just want to clarify something here. I'm not saying that with automated tests you're going to release bug free code. That's not true with what you release is often Soffer of better quality Now as you talk to various developers about automated testing you come across two extreme viewpoints on one side of the spectrum. We have developers like our John Smith who thinks automated testing is useless. On the other side of the spectrum we have this guy who thinks you're not a coder. If you don't write tests what I wanted to do is ignore both these extreme viewpoints. Instead take the middle ground and be pragmatic. The reality is even the automated testing has a lot of benefits. It doesn't fit every project and every team for the starter Your team needs to have a discipline in writing clean tests and maintaining them. If you don't work in a team like the writing automated tests ends up costing you more than the value you get out of them because you will spend a lot of time fixing broken tests that are hard to read and hard to understand. In those cases it's better not to write tests at all. Another factor is the time and budget of your project. Let's say you're part of a startup company and you have three months to turn a concept into real work in software. In this situation I argue that you should not spend your time writing tests initially because you don't know if this application or this business is going to succeed. Most startup companies have a small budget and they want to produce something quickly so they can show it to a mass audience and then attract venture capitalists to raise funds. If you want to spend three months writing tests chances are your application may not even make it to the production. So what's the point of writing all these tests. Plus in a lot of startup companies the requirements change frequently. If you spend a lot of time writing tasks a lot of these tasks break as you modify the application code to implement the new requirements. So in those projects it's better to write tests only for parts of the application that would take more time to test manually. So use it as a practice to help you increase your productivity and go faster as opposed to a hard and fast rule that you need to apply everywhere. Remember the real world is different from books and courses in the real world. We have constraints and most of the time these constraints are money and time. You cannot cause forever. You cannot code for fun. Your job is to build real work in software and solve a problem. Your job is to deliver value to the world. If you cannot deliver work in Soffer in time within the budget. Nobody cares about all your fancy automated tests. So once again I want you to be pragmatic and use automatic testing when it makes sense. Even if you cannot practice automatic testing in your current project or team I strongly recommend you to watch a section thoroughly and learn automated testing because it will help you become a better developer. It will enforce you to write better and more reliable code Marsh. I got it. Now tell me how should I write tests. Well that's the topic for discussion. So next let's take a look at the different types of tests.