Software testing basics, software testing details

Software testing basics, software testing details

In fact, in software development, a specific software engineer is in a team for testing. Maybe we directly discover the Bug when writing the code, and then solve the Bug, in fact, this may lead to a potential Bug that we don't know, which is neglected, or that we found this Bug after writing for a long time, but it has already penetrated into your project, in fact, when we develop ios, there will be such a framework XCTest. If we can apply it well, it can help us reduce some problems.

The following is an explanation of the test in Apple's official documentation.

All software is built using composition; that is, smaller components are arranged together to form larger, higher-level components with greater functionality until the goals and requirements of the project are met. good testing practice is to have tests that cover functionality at all levels of this composition. XCTest allows you to write tests for components at any level.
It's up to you to define what constitutes a component for testing-it cocould be a method in a class or a set of methods that accomplish an essential purpose. for example, it cocould be an arithmetic operation, as in the calculator app used as an example in the Quick Start chapter. it cocould be the different methods that handle the interaction between the contents of a UITableView and a list of names you maintain in your code's data structures. each one of those methods and operations implies a component of the app's functionality and a test to check it. the behavior of a component for testing shoshould be completely deterministic; the test either passes or fails.

The more you can pide up the behavior of your app into components, the more detailed tively you can test that the behavior of your code meets the reference standards in all participant ulars as your project grows and changes. for a large project with your components, you'll need to run a large number of tests to test the project thoroughly. tests shoshould be designed to run quickly, when possible, but some tests are necessarily large and execute more slowly. small, fast running tests can be run often and used when there is a failure in order to help diagnose and fix problems easily.

Tests designed for the components of a project are the basis of test-driven development, which is a style of writing code in which you write test logic before writing the code to be tested. this development approach lets you codify requirements and edge cases for your code before you implement it. after writing the tests, you develop your algorithms with the aim of passing the tests. after your code passes the tests, you have a foundation upon which you can make improvements to your code, with confidence that any changes to the expected behavior (which wocould result in bugs in your product) are identified the next time you run the tests.

Even when you're not using test-driven development, tests can help reduce the introduction of bugs in your code as you modify it to enhance features and functionality. you inactivate ATE testing in a working app to ensure that future changes don't modify the app's existing behavior other than in your planned ways. as you fix bugs, you add tests that confirm that the bugs are fixed. tests shoshould exercise your code, looking for both expected successes and expected failures, to cover all the boundary conditions.

The translation is

All software is integrated. That is to say, a smaller component is combined to form a larger and more advanced component with greater functions, until the project goals and requirements are met. A good test practice is to test the coverage function at all levels of the combination. XCTest allows you to write tests for any level of components.
You can define components of a test component-a method in a class or a set of methods to accomplish a basic goal. For example, it can be an arithmetic operation, just like the calculator application used in the Quick Start section. It can be a different way to process the interaction between the UITableView content and the name list maintained in the code data structure. Each of these methods and operations means an integral part of the application's functionality and a test to check it. The behavior of the test component should be completely determined; the test either passes or fails.
The more you divide the behavior of your application into components, the more effectively you can test the behavior of your code to comply with the reference standards of all details when your project grows and changes. For a large project that contains many components, you need to run a large number of tests to thoroughly test the project. If possible, the test should be designed to run quickly, but some tests must be large and run slowly. Small and fast-running tests can be run frequently and used in case of faults to help diagnose and fix problems.
The test designed for the components of the project is the basis for test-driven development. This is a code writing style, and the test logic is written before the test code is written. This development method allows you to encode the requirements and boundary conditions before implementing the code. After writing the test, you developed your algorithm to pass the test. After your code passes the test, you have a foundation. You can improve the Code and believe that during the next test, any changes to the expected behavior (which leads to errors in the product) are identified.

Even if you do not use test-driven development, testing can help you introduce bugs when modifying code to enhance features and functions. You added a test to a work application to ensure that future changes do not change the existing behavior of the application, not the way you plan. When you fix a bug, you will add a test to confirm that the bug is fixed. The test should execute your code to find the expected success and expected failure to overwrite all the boundary conditions.

Here we will introduce the meaning of test-driven development, that is, TDD. Simply put, we will first write a test based on our needs, continue to modify it without passing the test, and then perform a test in combination after passing the test, if the test fails, rebuild the test, update the failed test, and then combine the test to all tests.

In fact, the advantages of testing and componentization are very obvious, and there are many types of testing, such as fault injection, regression testing, static testing, dynamic testing, and so on.