Intro into Testing!
Today I would like to touch on testing through the eyes of a developer (not a test developer). What is app testing? Why should I test? What do I test? These are all wonderful questions. Although it may not be profitable in a company, for a developer to write tests, just knowing about testing can help improve our code as a developer. So let’s touch on some key points.
What is Test-Driven Development(TDD)? In Development we ask the questions do I write my test first which is known as test-driven development or do I write my application code first? If you are running solo, this is a difficult question to handle, and is best left to the situation. While in most companies, we see a branch of testers, writing tests while developers write the application. This is most proficient because if a developer spends the whole time writing tests, chances are they won’t make the production deadline.
What are the ways of Testing?
What is automated testing? Automated testing is the practice of writing code to test out code, then running those tests in an automated fashion. Say we have a simple function called add_sum that takes and input and depending on certain conditions returns different values. With automated testing, we can simply write code that calls this function with different inputs and run the code in an automated fashion. We can now test this function with automated testing, very fervently with many many scenarios, and outputs. With this practice, we can test the functionality of our code, several times faster without ever having to launch the application.
What is manual testing? Manual testing is just how it sounds. In manual testing to test this function, we might have to start a server, launch the application, maybe log in or sign up, click here, click here to get to the target page. Then we have to enter values in the fields so that eventually this function is called. This is very time consuming, and our insight is limited.
Now In the mind of an opinionated tester or developer, they might argue that writing the test code for each function, might take just as much time. As part of the development, it takes time to write and maintain our automated testing. So let’s break it down and see how they compare. In a small application, this argument is valid, but when we reach bigger applications with multiple functionalities the manual testing time increases after time mostly as someone has to manually tests these functions and they may not know what they do, or the expected outcome. With automated testing, the time taken decreases over the number of functions given. Another plus with automated testing, we can catch the defects before releasing or serving your software.
What are the types of tests? In general, we have three types of tests, to apply to our code. Unit testing, Integration testing, and End-To-End testing. Ideally, we like to stick with the unit or integration testing, let’s see why, and how it compares to our original code.
In a Unit test, we test a component in isolation, without external resources, such as a file system, database, or API. Basically, we offer the component fake instances of these attributes, to follow through with the test. It should contain small functions or methods, with proper naming conventions, and single responsibilities. While this works and is very easy to implement, it is not very reliable, due to the act of offering fake instances. Say while our fake server may have no problems handling the information, our real server may encounter compiling issues.
An Integration test is the exact opposite. We test the component with the actual resources that are needed. Again It should contain small functions or methods, with proper naming conventions, and single responsibilities. This calls for a little more code and implementation but gives us a better insight into the errors. This again deals only with a single Component.
With End-To-End Testing, we test the application as a whole. We go through all the steps necessary, serving to the browser, signing up, logging in, and clicking on all the desired functions. While this is a great approach, there is a pitfall. One it takes a lot of time, two if you find a bug and make a change it could break the rest of the app.
What to test? Is a question asked by many developers, but is pretty straight forward. You want to test any given or unknown instance that can break your app. Of course, you want to start by testing the basics. Assuming you wrote good reliable code that is efficient in serving on the browser, you will want to move on to all your functionality. Sign Up, Login in, Authentication, error handling for incorrect credentials, Signing out, and any functionality your app offers. Next, we need to take this a step further and take in the account of unorthodox use, or application abuse, to make a solid application. Say we have a function called greet which prints out a users name, while this is pretty straight forward we can imagine ourselves using manual testing, with a unit or integration test, or even save it for End-To-End testing. Now let’s say we have a function that calculates the price of our cart and outputs the total in the users local currency. There are lots of variables here such as: Are there discounts? Are there multiple purchases of a single product? Where is the user located? Is there a sale going on? Is the user trying to abuse the app by using an expired or already used discount code? While you can see the complexity of this code, it might be best to take an automated approach with an Integrated test approach.
There are a few more types of testing, such as Regression testing, Smoke testing, Alpha and Beta testing, Performance testing, and Stress testing, to name a few. There are also many types of Testing software such as Jasmine, Karma, Mocha, Cypress, and Jest to name a few. While it’s very possible to write your own tests, these programs really One up your testing game, each with their own pros and cons for different languages. While I could go on for a while on testing, I am a developer and not a tester. This was solely to help a developer get a better understanding of the next steps, or if they’re working in a company, what happens with their code next. Hopefully with this in mind, we can write better code, that will make everyone happier in the long run. This taken with a grain of salt can save us time, money, and risk of pulling our hair out, when we encounter problems. Thank you for reading, I hope you enjoyed.
