Explore a more complete front-end testing strategy

In particular, it is important to note that IT3 is a fully reusable E2E code, and IT is the general testing strategy mentioned above that is often not able to reuse E2E code.IT2IT2 is an integrated test of the minimum set of UI and the minimum set of domain modules, and it is also based on the mock service (including server APIs/DOM/BOM), because it is the module that starts the minimum set, so its test run speed and the operational performance of the minimum set can be guaranteed, it is faster than IT3..At the same time, it IT3 and has a good partition, IT2 is responsible for the minimum set, and IT3 is responsible for the overall collection..In addition to the minimum set, writing IT2 and IT3 is not very different, it can satisfy the mapping relationship through AC..Of course, unless there is a problem with the non-dependent module at the bottom, it is actually easier for us to pass the IT2/IT3 test report to bugs’s positioning.IT1IT1 is just the minimum set of modules integration tests, it only requires the mock back-end server APIs, because it only starts the minimum set domain modules, so it is faster than IT2 run..One or more steps in AC are capable of being converted into IT2 tests..Through IT1/IT2/IT3 ‘s test report, it is also easier to infer the location or cause of bugs.UTIn IT2 talking about testing problems with the underlying modules (less dependent modules or non-dependent modules), we recommend that such modules be suitable for more complete UT, especially core functions, and that the core modules of other modules, or helper functions, can be considered for unit testing, and that in many cases, Can help AC cover more examples..It is an important addition to IT1/IT2/IT3.Among the different test types, the test factors covered are also different..Then we hope that with such a test strategy can be more complete and efficient to meet the various factors of testing: The E2E test covers almost all of the test factors, IT3 is less than E2E real server APIs and real browsers, IT2 is less than T3 a number of non-essential modules and UI components, IT1 has fewer UI components than IT2, and UT only covers a small number of core logical parts.In such a test strategy, we can develop a better strategy to run the test code, we can run ut/it1 when submitting commit, we can run PR when we submit the UT/IT1/IT2 or even IT3, And at the time of our return or when we run the E2E regularly (a week or a few days)..In such a operating system, we can ensure that the AC is guaranteed to be verified, but also to ensure a certain degree of operational efficiency balance, while different types of test reports will also contribute to the positioning of the bugs.How to implement building this more complete testExample for business code:@Module()class Foo { a() {} _x() { //No dependent module core logic }}@Module({ dependences:['Foo'] })class Bar() { b() {} _y() { //No dependent module core logic } get name(){}}@Module({ dependences:['Foo', 'Bar'] })class Foobar() { c() {} get name(){}}const store = createStore( //…factory module);const FoobarContainer = (props) => ( <div onClick={props.foobar.c}> {props.foobar.name} </div>);const BarContainer = (props) => ( <div onClick={props.bar.b}> {props.bar.name} </div>);class App extends Component { render() { return ( <div> {this.props.foobar?.( <FoobarContainer {…this.props}> ): null } {this.props.bar?.( <BarContainer {…this.props}> ): null } </div> ); }}render( <App store={store} />, mountNode);Example for acceptance criteriaFeature: AC Scenario Outline: Given User saw 'b' node When User click 'b' Then User should see 'b' changed When User click 'f' Then User should see 'f' changed Scenario Outline: Given User saw 'c' node When User click 'c' Then User should see 'c' changed When User click 'e' Then User should see 'e' changedExample for testing// E2E & IT3test(() => { const app = getApp(); app.find(nodeSelectorB).click(); expect(result).toBe(expectedValue1); app.find(nodeSelectorF).click(); expect(result).toBe(expectedValue2);});test(() => { const app = getApp(); app.find(nodeSelectorC).click(); expect(result).toBe(expectedValue1); app.find(nodeSelectorE).click(); expect(result).toBe(expectedValue2);});// IT2test(() => { const barContainer = getMinimalSet(BarContainer); barContainer.find(nodeSelector).click(); expect(result).toBe(expectedValue2);});test(() => { const foobarContainer = getMinimalSet(FoobarContainer); foobarContainer.find(nodeSelector).click(); expect(result).toBe(expectedValue1);});// IT1test(() => { const app = getMinimalSet(Bar); app.b(); expect(result).toBe(expectedValue);});test(() => { const app = getMinimalSet(Foobar); app.c(); expect(result).toBe(expectedValue);});// UTtest(() => { const result = Foo.prototype._x(); expect(result).toBe(expectedValue);});test(() => { const result = Bar.prototype._y(); expect(result).toBe(expectedValue); });ConclusionThere are many factors we need to consider when developing a test strategy..From the point of view of correct verification based on AC, we should also consider the operation strategy, operating efficiency, writing and maintaining the cost of testing, bugs easy to find and refactoring assurance and other important factors, and should not go to extremes.. More details

Leave a Reply