In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >
Share
Shulou(Shulou.com)06/03 Report--
Recently, a colleague complained that their tests were difficult to write, often spent more time on testing than on production code, and had to modify a lot of tests after each refactoring. After chatting with colleagues, I learned that there is a heavy use of mock in its project, or the excessive use of mock is extreme to the so-called "fast" and "independent" unit testing. In the previous reprint, "there is no right method in software development", when you use a methodology as a silver bullet, sooner or later the devil will be with you.
Mock brings me awareness, strips off class-to-class dependencies, and helps us work better on current concerns. But at the same time, due to too many assumptions about the scenario, this code has become an isolated island of information, and even have to use verify,order, the second feature of mock, so that your test is no longer concerned with the business logic of the code, but tends to the design and implementation at the code level, which pushes your unit test to the position of "white box test", causing the test to become a fragile test. Whenever simple refactoring leads to internal changes, your tests must change as well.
I think that as a good test, under a legal simple refactoring, there is no need to modify the test, because what you modify is only the internal implementation, not the change of business, if you change the test while refactoring or refactoring after hanging on a lot of tests, which means that your test is not a stable test or you are not a legitimate refactoring (maybe redesign,override).
In a colleague's project, mock is so extreme that it also uses builder mode for simple View Object, but it is full of mock given inside. In my opinion, View Object is just a simple data carrier, there is no behavioral logic, we do not need to do mock,mock should be aimed at assumptions, but should try to avoid state mock. Before you need to write a test in a colleague's project, as a preparation for the test given, you must understand the implementation of the existing code, because you need a bunch of given, for example, for person objects, if you need to get account in the implementation:
Given (person.getAccount ()) .willReturn (some account)
As a result, I need to understand what property is needed for my implementation. If I need a new property, I may simply put an "attachment complex" into object, and the test also needs to be modified, resulting in reconstructors being less confident about their own refactoring, which will affect refactoring into daily behavior, as the accumulation of "bad smell" will erode your code bit by bit, and the project may slowly get out of control.
Mock is not a bad thing, the result is good or bad depends on the user, team consciousness, if it is mock anywhere or stop mock to go to two arbitrary extremes will be a wrong choice.
More use scenarios of Mock are de-dependence on external resources to enhance awareness, as well as the verification of important business without response, which is reflected in a method without returning sub-void, but method such as increasing user points and recording user information. However, for responsive business, what I need is not mock but assert. For business, the test is that my input should get the response I expected, not that I verify some behavior happened, then the result must be correct. Of course, this is true for implementation, but it is meaningless in terms of the value of the test. This will be a fragile test. I think a good test would be a "black box test", a description of a business, a statement of an agreement, a contract.
Postscript, if you prove for your mock because of the speed and independence of the test, it will be meaningless, not every test must be within the Golden Rule (0.1s), if you rely on external dependence, time-consuming dependence separation, which I believe will no longer be the problem, test optimization will be another interesting topic, will not be the content of this question.
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.