――I've never done test code or test automation before, and it's been a little over half a year since I joined the current company and started writing test code. --Language is mainly php, javascript (node) ――Before writing the test code In order to raise the reason and motivation for writing the test code, I will summarize the test code and the test, including the feeling that I am currently writing.
--1960s
--The method of test automation was considered as early as 1962.
--Software crisis
――The story claimed at the 1st NATO Software Engineering Conference at the end of the 1960s, it was called out that the complexity of software development will accelerate due to the higher performance of computers.
――Around this time, discussions on software development methodologies such as structured programming and automated testing have begun to become more active in response to the increasing complexity of software development.
--1970s
--Software Testing Techniques 1976
--As software became more complex, test methods for improving software quality were examined and established.
--Object-oriented programming
--In order to deal with the complexity of software, the object-oriented way of thinking that programming is likened to an actual object (thing) has begun to become popular.
--1980s
--The Mythical Man-Month (no silver bullet) 1988
--A famous paper on software development. In software development, he left behind the famous phrase there is no silver bullet, which means there is no one-size-fits-all way to deal with any event. Another well-known Brooks' law is that adding personnel to a software project that is delayed only delays the project even further.
--1990s
--Extreme Programming (commonly known as XP) 1999 The method itself has been around since 1996
--A book on development methods written by kent beck, who is also famous as a developer of small talk. It contains the main ideas of modern automated testing ideas. (Details will be described later)
- Scrum
--One of the agile development methods. I have the image I hear most often these days.
――A method of creating a product by forming a sprint in a short period of time and working together with the Scrum Master, product owner, and team.
――The Scrum Master will help you introduce Scrum, the product owner will work on the product with business requirements and responsibilities, and the team will work together to meet the business demands of the product owner.
――There is no detailed description about test automation in the development method proposed at the same time as XP, but test automation is basically introduced as a method for developing in a short period of time.
--2000s --Lean Startup ――Strictly speaking, it is not a software development method, but an entrepreneurial methodology, but it is a development method often used by start-up companies. One of the agile development methods. A method of creating a minimum viable product (MVP), repeating hypotheses and verifications, and improving the product. Repetitive tasks and methodologies have much in common with XP and agile methods. - DevOps --A portmanteau that combines development and operations. A development method in which development personnel and operations personnel cooperate and cooperate. A development method that seamlessly links operations, infrastructure, and development. The introduction of test automation along with infrastructure automation has been advocated.
--Test type. The following words may be used as the test phase, but here they are classified as the type of test. There are various names depending on the company.
--Test to check if the function of each module is satisfied --Commonly known as UT (Unit Test) --Basically done by white box test
--Concatenate and test each module --Commonly known as IT (Integration test) --Function test function test is similar to here --In some cases, tests for external connections such as external APIs are performed step by step. --Basically a black box test, sometimes a white box test image
--A test that combines all conditions such as external API and browser --Prepare an environment equivalent to the production and perform the test. Here we check if the program works as required --UAT (User Acceptance Testing) --Basically done by black box test
--The viewpoints to be tested that should be considered when conducting software testing can be broadly divided into functional requirements and non-functional requirements.
--Parts that meet client requirements --Check if the code you created meets the functionality required by the client and if it works correctly as required. --The part that can be secured by the test code is basically this part
--Parts other than specifications and functions --Information security
--Test analysis --Test design
--Unit test, commonly known as UT (Unit test) --A test that confirms that the code is working as the developer intended ≠ A test that guarantees business requirements --Create for each method. Fine particle size --Test the parts that depend on other modules as stubs and mock
--Functional test --The part where each module (external API and DB part) is connected is also tested. Large particle size --Test multiple modules together, including whether the program meets the requirements
--Tests performed using software that runs actual browsers and apps such as selenium and appinum have the highest granularity.
--A long-lived project that considers maintenance --Projects with many changes in specifications and frequent changes in people
--To reduce the cost of testing ――Since unit tests run the code comprehensively, I think that the cost of regression testing can be reduced once it is written. --Because the code is easy to test, you will be aware of loosely coupled programs. --Because the test code itself becomes a specification for programmers ――By thinking about the test code, you can deepen your understanding of the requirements.
--The importance of test code is generally said to be in the order of unit tests> functional tests> UI tests. ――It is important for fine-grained tests such as integration tests because you can check the specifications, but the conditions are complicated, which makes test maintenance complicated, and when a bug occurs, which part is the cause of the bug? Since it is difficult to understand, the basics of expanding from unit tests where the granularity is small and it is easy to fix tests and find bugs.
--Reduce programmer stress --The program is a stressful task --You have to understand the specifications ――Write in consideration of various things such as abnormal system as well as normal system ――In the first place, you have to think about how to express it in the program. ――If the specifications change, you have to remake it ... --You have to think about performance and readability ... --Easy to change etc ... ――The programmer has to write the program with various considerations. ――It is very difficult to write proper code at once. There may be changes in specifications. --I don't know where a program without test code will break. --Write test code -→ Make it easy to see what broke when refactoring -→ Reduce programmer stress
――The cost of writing test code is half that of the implementation, which is fast for experienced people, and 1.5 to 2 times the cost of the implementation, which is the same as the implementation for the unfamiliar people. (Personal skin feeling) --When introducing test code to code without test code, the cost of introducing test code is often high because the code itself is not aware that the test code is written. --The test code also incurs maintenance costs that change when the code of the main unit is changed. --Introduction of test code environment, cost of learning how to write test code itself
--Development method to replace the waterfall type proposed in the 1990s --The book was compiled in 1999 ――One of the origins of the current development method called agile —— Consists of 4 values, 5 basic principles and 19 best practices ――The conventional waterfall is characterized by a method of repeating development in a short cycle and improving little by little, compared to the method of proceeding to the next process after the previous process is completely completed.
TDD(Test Driven Development)
--Test Driven Development
--Advocated by kent beck as one of XP best practices
--XP and test code
――XP is premised on development in a short cycle, and the requirements and code are constantly changing, and programmers refactor in a situation where it is difficult to fully understand all of them. Test code helps you to courageously tweak that changing code
--A method called test-first, in which you write a failing test first before implementing it, and then start implementing it.
--BDD and FDD are development methods for development (I'm not familiar with it because I haven't done it before)
--One of the basic methodologies of TDD, a method of writing a test before implementation, deciding the interface of the implementation content, and then implementing it to ensure the behavior of the implementation and to have the test code at the same time as the implementation. ..
Improve the code by going through the cycle of Red → Green → Refactor for the code.
--Procedure
--Write a failing test that describes the method content IF and the output result (Red)
--Failed test Proceed with implementation and make test successful (Green)
--Change the code content so that the completed test does not fail, and add tests as needed (Refactor)
--If there is a code change, write a failing test again, implement the code according to the test, and cycle through the cycle.
--Basically, there are many xUnit systems including materials, so unless you have a specific reason, it is better to use the xUnit system of each language. --Test framework for each language (example)
--In the project to introduce the test code, it is advocated to introduce an environment to automatically execute the introduced test code. It is built using jenkins, etc., and recently, services specializing in CI functions such as Circle CI and Travis CI are also being developed.
--Team cooperation --Get the man-hours to write the test code --Common environment for writing test code --Automate test execution environment --Write a sample code so that other people can write it because it can be copied at first --Detailed requirements early to write test code early
--When creating an MR / PR of an implementation, attach the test code (at least normal system) of that implementation together. --The review side can also check the implementation contents with the contents of the test code, and you can also test the confirmation of the code. --Think about test code priorities ――It is important to expand the test properly, but the progress of the project and the degree of determination of the requirements determine the test that is advantageous to write at that time. --Example --If the requirements are fluffy --First, write a functional test that guarantees requirements with loose verification content, and then write a fine-grained test after fixing the requirements. --If the requirements are clicked --Write from the unit test (I want to write) --About the scope, name and meaning of the test ――I want to separate the definition range that refers to unit tests and functional tests. ――If it is a unit test in a pure sense, should all the parts that depend on other methods be mocked or stubed? I also think that, depending on the range you want to check, if you want to combine a little, is it called integration test? If so, I think that the range that the word integration test refers to is too wide. Or, I want words that can organize the scope and meaning of the Mouchi test. .. ..
――The test code has many advantages, but it is not a silver bullet that is effective in any situation.
――But I think having the courageous option of writing test code can bring good results.
――I think there are still some misunderstandings and shortages due to lack of study, so I would be grateful if you could make various editing requests.
Recommended Posts