The Way to Neat Code - Reading Notes (7)

The Way to Neat Code

Synopsis:

This book is a summary of the experience of programming guru "Uncle Bob" over 40 years of programming career, explaining what kind of attitude, what kind of principles and what kind of actions are needed to become a real professional programmer. The author takes the detours and mistakes he and his colleagues have made as examples, with the intention of guiding those who come after him and helping them to take a higher step in their careers.

This book is suitable for all programmers and can be used as a reference for all those who want to become professionally literate in the workplace.

Chapter VII. Acceptance testing

Professional developers are as much about development as they are about communication. "If the input is bad, the output will be bad" applies to programmers as well, so professional programmers will emphasize communication with their teams and business units to ensure that this communication is accurate and smooth.

7.1 Communication of needs

Premature refinement

People in business and people writing programs tend to fall into the trap of doing refinement too soon. The business side wants to know precisely what they will get at the end before they have even started the project; the development side wants to know precisely what they will deliver before they have even evaluated the entire project. Both sides crave unrealistic precision and are often willing to spend a lot of money in pursuit of that precision.

Uncertainty:

In the workplace, there is a phenomenon called the observer effect, or the uncertainty principle. Every time you show a feature to the business side, they gain more information than they had before, and this new information in turn affects their view of the overall system.

Anticipatory Anxiety:Needs are bound to change, so striving for that kind of precision is futile.

Late Ambiguity:

The way to avoid premature refinement is to delay refinement as long as possible. Professional developers don't flesh out requirements until the moment before they embark on development. However, this can create another problem: belated ambiguity.

Every bit of ambiguity in a requirements document corresponds to a bit of disagreement on the business side. Of course, ambiguity doesn't just come from disagreements or arguments. Sometimes the business side takes it for granted that the people reading the document know what they are talking about.

7.2 Acceptance testing

In this chapter, we define an acceptance test as aTests written by the business side in collaboration with the development side with the purpose of determining that the requirements have been completed.

Definition of "completion"

Completion meansAll the code has been written, all the tests have passed, QA and the requirements side have recognized theThat's what I'm talking about. This, then, is the finish.

So how can you achieve this level of completion without compromising the speed of iteration? You should write the entire set ofautomated testIf they all pass, it means that all the requirements have been met. If all the acceptance tests for a feature pass, it is truly complete. Professional developers define requirements based on automated acceptance tests. They work with the business side and QA to ensure that the automated tests actually cover the metrics required for completion.

Communication:

The purpose of acceptance testing is communication, clarification, and precision. The developer, business, and testing parties reach a consensus on acceptance testing so that everyone understands what the behavior of the system will be. This precise consensus should be documented by all parties. In the professional developer's view, it is his or her responsibility to work collaboratively with the business side and the test side to ensure that everyone understands what is to be done.

Automation:Professional programmers will avoid this. The cost of automated testing is so low compared to manual testing that it is not cost-effective to have test scripts executed manually. Professional developers consider it their responsibility to automate acceptance tests.

Professional developers approach automation like thisExtra workattitudes:

Writing so many tests does seem like tons of extra work. It's not much extra work at all.

These tests are written to determine that the system's metrics meet the requirements. The purpose of identifying these metrics is to determine the metrics of the system; only by identifying these metrics can we, the programmers, know that it is "done"; only by identifying these metrics can the business side confirm that the system they are paying to develop is actually fulfilling the requirements; and only by identifying these metrics can we truly automate the tests! Only by confirming these metrics can we truly automate our testing.

So, instead of seeing them as extra work, they should be seen as a way to save time and money. These tests can prevent your development from going astray and can also help you confirm that you are finished.

When will the acceptance test be written and by whom:

Often tests are given to business analysts, QA or even developers. If tests can only be written by developers, it should be ensured that the programmer who writes the tests is not the same programmer who develops the functionality being tested.

Typically, business analysts test the "right path" to prove the business value of a feature, while QA tests the "wrong path," boundary conditions, exceptions, and exclusions, since it is QA's job to consider what could go wrong.

Following the principle of "postpone refinement", acceptance tests should be written as late as possible, usually a few days before the functionality is implemented. In Agile projects, tests are written only after the functionality required for the next iteration or current sprint has been selected.

Developer's Role:It is the developer's responsibility to link acceptance tests to the system and then let those tests pass.

• As a professional developer, it is your job to consult with the people who write the tests and improve them. Never accept tests passively, and never say to yourself, "Oh, that's what the tests require, that's what I have to do.
• "Remember, as a professional developer, your role is to assist the team in developing the best software possible. That means everyone needs to be concerned about mistakes and oversights and work collaboratively to correct them.

Acceptance Testing and Unit Testing Differences:

First of all, while both may test the same object, the mechanisms and paths are different. Unit tests are conducted deep inside the system, calling methods of a specific class; acceptance tests are conducted outside the system, usually at the API or UI level. So the execution paths are very different.

Their primary function is not really testing; testing is just a subsidiary function of them. Unit testing and acceptance testingDocumentation first, then testing. Their main purpose is to faithfully describe the design, structure, and behavior of the system. They can certainly verify that the design, structure, and behavior meet specific targets, but theTheir real value is not in the tests, but in the specific metrics.

Graphical interface:

• Better yet, when testing system functionality, the real API should be called, not the GUI.
• For decades, design experts have been teaching us to separate GUI from business logic.

Continuous Integration:

Make sure that unit tests and acceptance tests are run several times a day in the continuous integration system. The entire continuous integration system should be triggered by the source code management system. As soon as someone commits the code, the continuous integration system will start building and run all the tests, the results of which will be emailed to everyone on the team.

Continuous integration should not fail, and if it does, everyone on the team should stop what they're doing and see how they can get the test to pass. In a continuous integration system, failed integrations should be treated as emergencies, i.e. "abort now" type events.

reach a verdict

Exchanging detailed information can be a pain in the ass. This is especially true when the development side and the business side exchange details about the program. Often, the parties shake hands and assume that everyone else understands what they are saying. It's all too common for both parties to think they have a consensus and walk away with very different ideas.

The only effective way I know of to solve the problem of communication between the development side and the business side is to write automated acceptance tests.These tests are formal enough so that their results are authoritative. These tests do not create ambiguity and are not likely to be disconnected from the real system. They are, in fact, impeccable requirements documents.