Hi everyone. Here I am again with the 4th article of the Advanced Software Development series. If you've come this far by reading the series, it's fine. If you came directly to this article, I suggest you read the 0- Advanced Software Development article.
Now on to the subject of testing, "Why is testing so important when developing software?" I think we can start by looking for an answer to the question.
It is impossible not to make mistakes while writing code. We all make mistakes. While some of them are insignificant, some of them can be vital for the software. In such a situation, we may not always to be tolerated by our team leader, boss or customer.
After writing our code and revealing our product, we cannot catch the blind spots in the manual tests we do individually. Because we test our product from the perspective we have when writing. In such a case, we are likely to miss the same blind spots again.
When we look from a professional point of view, we see that the majority of corporate companies now use advanced project management systems. All of these project management systems, which pay attention to the software development life cycle, use software tests. The Software Testing Lifecycle (STLC) is an integral part of the Software Development Lifecycle (SDLC). While this is the case, it has become mandatory for us to write test codes. Otherwise, it will be very difficult for us to find a job in a large corporate company. Our advanced software development process will end at the beginning of the road.
Tested software enables you to provide customers with quality software that requires less maintenance, making you more reliable and professional.
A continuous verification and validation process is required to deliver a great product. Tests measure the performance and efficiency of the system/application, helping to ensure that the software is compatible with all technical and business parameters.
There are many different testing methods you can use to make sure changes to your code are working as expected. We can divide these into two main groups as manual and automatic tests.
Manual Test: It is done using the software personally. This is very costly as it requires someone to devote time to it. At the same time, since the tester is a human, there is a high probability of making mistakes.
Automatic Test: It is done by running pre-written test codes. Here, the tester is the machine itself. It is ensured that all conditions written in the test function are met.
Automated testing is important component of Continuous Integration (CI) and Continuous Delivery (CD) of DevOps tools . It is also an important part of the QA (Quality Control) process.
Test Types
Unit Tests
They are low-level tests used to test the functionality of classes, methods, or functions we create in software. Unit tests can be easily automated by CI (Continuous Integration) servers.
Integration Tests
It is the type of test where we test how well different modules or services used by our application work together. Since this test type requires interacting with more than one module of the software to be successful, it is more costly to run than unit testing. For example, integration tests can tests whether the interaction of some modules with the database works correctly or whether some microservices that are separate from each other in a software work as expected.
Functional Tests
Sometimes Functional Tests and Integration Tests are confused because both work with different modules. Functional Tests focus on the business needs of the application. It focuses only on the output of event. Unlike Integration Tests, it does not question the relationship of modules with each other. It is enough that the output is correct for this test to be successful.
End-to-End Tests
This test imitates user behavior. It is used to verify whether various user flows are working as expected. They are more costly to implement. They are more complex in structure. It is generally recommended to be used at a few different points of vital importance in a software. For the rest of the software it makes more sense to use the less costly Unit Tests and Integration Tests.
Acceptance Tests
User behaviors such as End-to-End Tests are emulated. Acceptance Tests are used to verify whether the application meets all desired business requirements. If not all requirements are met, the test will fail.
Performance Tests
As the name suggests, it is used to measure performance. They are often used to measure the response time of the system when executing a large number of requests or the behavior of the system under a heavy load. These tests are costly as serious server power is required. However, it is very important to implement it after major changes to be made in future software.
Smoke Test
Smoke tests are used to test the main features of the application. They are therefore faster. They do not need to be written for each module. It is enough to focus only on the main features.
Whatever programming language you use, there are definitely many different test options for it. For example, there are Appium, XCTest, Calablash, Detox, OCMock and EarlGrey test frameworks for iOS, while PHPUnit, Mocha and RSpec frameworks are used for PHP and JavaScript. You can find the best by doing research in the developer communities.
Tests can be run with the help of a compiler or directly from the command line, or they can be automated with CI from DevOps tools. (CI pipeline consists of Build-Test-Deploy steps. If the test phase, which is the 2nd step, is not passed, the application will never be deployed.)
Test Processes in Software
We have mentioned code quality in every article of the Advanced Software Development series. Now let's add one more to the code quality's properties. Quality code is also error-free code. To ensure this, we need to test the software. While software tests are written TDD, BDD, DDD, RDD, FDD, ATDD etc there are many approaches. I will briefly touch on the most commonly used TDD and BDD approaches. But my advice to you is to read at least 1-2 articles about other approaches. Even if you are going to use TDD, it is useful to at least know why you should choose it and why it differs from others.
TDD - Test Driven Development
This approach, released in 2003, is the most-used testing approach. The TDD approach is not a test type. It is more of a way of doing software testing, a software development tactic. The TDD approach requires that test codes be written before software codes are written. TDD helps the software to come out in a simpler and simpler structure as it requires the expectations to be determined beforehand so that the tests can be written in advance. This makes the quality of the software better.
In the TDD approach:
1- [Write Test] Write a test for a situation.
2- [Fail] The test is run. The test fails because there is no function/method that does this yet in the software.
3- [Refactor] The necessary codes are written/edited to pass the test. The test is passed successfully.
[Write Test] - [Fail] - [Refactor] steps continue in the loop. The application is subjected to a continuous refactoring process until the software is able to meet all the demands of the customer.
BDD - Behaviour Driven Development
In this approach, which was put forward in 2009, the TDD approach was tried to be facilitated. In line with TDD, tests are written in advance in the BDD approach too. Behavior Driven Development (BDD), as the name suggests, is a behavior-based software development method. Business analysts and developers determine the required behavior of the software with meetings.
In the BDD approach, three scenarios are establishing: "Given", "When", "Then". These scenarios are writting in colloquial language. Writing tests in spoken language are the advantages of BDD. Members who will join the team later can understand these tests much more easily.
Conclusion
After giving a brief overview of the testing approaches, you now know exactly what the "Test" folders were created for in the framework you are using. Just knowing is not enough, it is also necessary to use. If you want to find a job in corporate companies that manage their projects with Agile, the code you will write should be testable code. The easiest way to achieve this is to use one of the testing approaches.
While the importance of writing test code is sometimes difficult to understand, it should be measured not just by the cost and time spent, but by the great value it brings.
In the Advanced Software Development series:
Previous article: "2- Why/How to Write a Comment? What is Clean Code?".
Next article: "4- What is DevOps? What are the benefits? What tools does it use?".
Don't forget to like if you think it's useful :)
Always get better...
Top comments (7)
I've been a developer for 30 years and have developed lots of complex solutions. Sometimes from scratch other times integrating new functionality and most frequently upgrading current code.
The only way to survive long term is to have extensive tests which stop regression. By doing this, a confidence develops giving one the freedom to refactor at will. Software development is like surgery. Make one mistake and the patient suffers or dies. Why risk it? We don't have too when being disciplined in creating adequate tests for each push.
Surely then, It logically follows that we also cannot write automated tests for the 'blind spots' - since we fail to identify them in manual tests to start with?
I've been a professional developer for over 26 years and I write/use automated tests extremely rarely. I believe it is much better to develop a thorough enough understanding of the code you are working with to understand the implications of your changes, know how to test it manually, and be confident in your changes. If you write good code, this is almost always possible.
Relying on automated tests is dangerous and lazy - they often contain many layers of 'blind spots' compounded on top of one another. In an ideal world, this wouldn't be the case... but in my experience, sadly, reality is usually like this.
I disagree. And so does Agile and gated check-ins. I successfully write new tests for every push and have been doing it for years. It allows me to refactor at will.
Weirdly I kind of agree with both of you, I've seen a lot of projects where tests exist and pass but don't actually capture bugs that exist in the software. This gives a false sense of security. I'm guessing that John has a well developed sense of how to write tests for his code and therefore benefits from them greatly.
I personally find writing tests on the back end to be more helpful than exercising the code via a front end - for me its faster to develop. On the front end, I'd prefer integration tests to ensure we haven't broken flows.
First of all, thank you for sharing your ideas. I'm learning some things from all of you and it makes me think :)
I also partially agree with both of you. A manual test is always needed in projects where user experience is very important. But when working with DevOps teams, automated testing is vital to the process. Automated tests are also more cost-effective as they do not require constant control.
Hi Mike, true story: I once put in a fix on an IBM midrange that was declared defective in a week. Total cost was over $1 million USD because it went through 37 translations for each country. They didn't fire me, but I had checked out about 10 books on Software testing. The best was from Boris Bezier. That's how I picked up skilled testing techniques.
I agree BDD is a solution looking for a problem. Agile doesn't even mention it.