Discussion: feasibility and best practices of TDD in HTML & JavaScript

Document directory

• Digress
• TDD background
• TDD in HTML & JavaScript Overview
• Feasibility of TDD in HTML & JavaScript
• Best practices of TDD in JavaScript

Digress

I just wanted to launch a discussion on this topic yesterday. I just thought that the existing functions of the blog Park are not supported yet. So I suddenly found it difficult to initiate a valuable discussion in the blog garden. Comrade Alexander mentioned that "the discussion in the blog garden needs to initiate controversial topics, such as. net sucks ". Review the recent hot topics that have aroused discussion, such as the response to the recent C # debate. Sigh deeply. The recent C # debate is lucky. Despite a lot of slots in the middle, Mr. Li Jianzhong's participation eventually leads the topic to the correct direction. Lucky. I have benefited a lot from this audience. It is not just a correct understanding of this technical topic, but also the strange atmosphere that Mr. Li mentioned at the end of his blog: throwing away the "have to argue about winning or losing each other, instead, we come to some solid technical Reasoning Processes and believe they will be more meaningful-if so, the domestic technical community will grow.

Let's get down to the truth and start the topic that I want to discuss as soon as possible. No matter what the final effect of the discussion is, we should first share our ideas as much as possible to show our sincerity.

TDD background

Beck was officially proposed in (in fact, In, Beck proposed the term eXtreme Programming) countless practices have proved that Test-driven design/development is a revolutionary development method based on Test priority, refactoring, and iteration,Suitable for TDD FieldsTDD can greatly improve code maintainability and development efficiency.

The basic flowchart of TDD is as follows:

In such an iterative process, before writing any production code, write test, then the production code, and constantly clean and refactor the code, in addition, regression testing is required for each iteration to ensure that the new test and production code does not break any existing test and production code.

Generally, tools that support automated regression testing are relatively easy to implement. The difficulty in the whole process is: When writing the test code first, it is necessary to define the external interface of the tested production code first. For the first iteration, there is no problem. However, changes to requirements or overall design often occur in subsequent iterations, existing external interfaces that have been implemented and contain the complete production code need to be changed or reconstructed. Although theoretically, most of the reconstruction requirements are regular or even pattern-based, manual operations are not only inefficient, but also prone to errors. Therefore, all successful TDD practices lack many reconstruction tools. For example, most of the current integrated development environments have many automated code refactoring tools, greatly reducing the cost of code refactoring.

However, in some other fields, TDD is still a little inadequate, or at least, so far, we have not seen many good practical cases. For example, for Database and UI.

The main challenge for TDD in database development so far is tool support. Both automated regression testing tools and refactoring tools are far from mature enough.

TDD for UI is the topic of this article.

TDD in HTML & JavaScript Overview

When talking about the application UI, there are actually two aspects: look and feel with pure graphics; and interaction between users and applications. The interaction between users and applications often leads to changes in the graphic interface and changes to New interactions.

Since the main work practices are WEB-based HTML and JavaScript projects, here we will focus on the TDD in UI Based on HTML and JavaScript.

At the same time, in general, the presentation layer of WEB programs mainly includes client code and server code, while server code is relatively easier to be tested. Therefore, the focus of this article is mainly on the client code. In other words, the TDD in HTML & JavaScript discussed here refers to TDD for the HTML and JavaScript of the client.

Feasibility of TDD in HTML & JavaScript

The feasibility can be divided into two aspects: theoretical feasibility and practical application feasibility.

The first question is: can the look & feel of pure graphics perform automated testing theoretically? The answer is almost no. Therefore, HTML and CSS are mainly used to present pure images, and it is almost difficult to perform automated testing.

In theory, can the interaction between users and applications be automated? There is no doubt that the answer is yes.

WEB interaction testing can be divided into two types based on the WEB program architecture:

1. Traditional WEB programs mainly present content based on the server, and the interaction between users and pages, mainly get, post data and page Jump. Therefore, the corresponding test method is to simulate the data that requires get or post by the test tool and track the expected page Jump. In this case, the test is relatively simple, so this article does not want to discuss it too much.
2. The current AJAX-based WEB program enriches the ways in which users interact with pages. In addition to the traditional get, post data, and page Jump, when the page is not refreshed, it also triggers various DOM events, or even directly triggers the execution of JavaScript methods. The content is changed and presented by JavaScript. In this case, traditional test tools that can only simulate data that requires get or post are powerless. At this time, because all the logic code is in JavaScript, it is essentially necessary to test a large amount of JavaScript code. This is the focus of this article.

First, there are already many automated testing tools for JavaScript, such:

• JsUnitTest
• QUnit

Mock tools also include:

• JqMock
• JSMock

There are relatively few tools to directly refactor JavaScript code, and the functions provided are also very weak:

• IntelliJ IDEA
• Eclipse

From the status quo of supporting tools, we can say that one of the factors that affect the practical feasibility of TDD in JavaScript is the lack of refactoring tools.

However, there have been some changes in the recent situation, and there are also some alternative solutions that support JavaScript refactoring, such:

• Script #-Write C # code, compile C # source code directly to JavaScript code
• Jsc-Write any. NET code, convert. NET assembly to JavaScript, ActionScript, java or PHP code

These solutions are characterized by the use of existing IDE To improve the coding of popular programming languages such as C # source code, especially the support for strong types, refactoring and testing, developers are allowed to write C #, which is converted from a tool to a JavaScript code that can be directly executed and formatted. In addition to fully utilizing IDE's coding support for popular languages, another benefit of this type of solution is that Junior's C # developers are much cheaper than those who hire Senior JavaScript developers with high salaries, it is also easy to recruit, but thanks to Script #, it is enough to use the C # They are familiar with to write JavaScript code with complicated logic and OO. Therefore, the development cost is greatly reduced.

To sum up, TDD in JavaScript is not only theoretically feasible, but also has enough tool support in practical application. Especially the emergence of tools such as Script # greatly improves the development efficiency of JavaScript code.

Best practices of TDD in JavaScript

Everyone hopes to have best practices. What is best practice? Many people cannot see the word "best" or "most". They believe that there is no "most" thing in the world. Yes? Of course! First of all, we need to rise to the height of philosophy. If we want to be a true proposition for a proposition that contains "the most" words ", therefore, an appropriate precondition must be added.

For example, I said, "I am the most NB-savvy person in the world ". This is undoubtedly a false proposition. Because there is a lack of appropriate prerequisites. You can make an exercise by yourself. If you think this proposition is false, you can find a way to add more preconditions to it to make it true.

Therefore, the so-called best practice refers to a model of practical solutions that can be taken against one or more specific problems under a relatively definite background. With the prerequisite, the "best practice" certainly exists and deserves discussion.

Through the previous sections, We have restricted the topics discussed in this article to a relatively small scope, that is, a large amount of JavaScript code in AJAX-based WEB applications, how to perform TDD?

In addition, we have collected enough tools required to support TDD, including automated testing tools, Mock tools, and refactoring tools. With the support of these tools, the TDD of the JavaScript code on the WEB Client and the TDD of the server code should not be very different. But at the same time, due to the special nature of the client code, there should naturally be some practices specific to the client script code.

The following lists some of my Recommended Practice modes. I hope you can fix them together.

Best Practice 1: Use the MVC Mode

In traditional non-ajax web programs, JavaScript is often very auxiliary. In addition to implementing some special effects and data verification and other auxiliary functions, JavaScript code on a page may be very few. It doesn't matter whether it is tested or even TDD.

However, in today's complex AJAX applications, functions that can be combined only by get, post, and page Jump on multiple independent pages can be implemented through JavaScript, it can be easily implemented on a page without refreshing the browser, not only better user experience, faster speed, but also less load on the server.

In this case, the server of a traditional WEB program needs to handle problems, such as data binding, event binding, and logical control. Therefore, the MVC pattern, originally designed to solve the testability problem of WEB application server code, can be well applied to the client. By clearly dividing JavaScript code into M, V, and C, the same logic responsibilities can be managed together as much as possible, greatly increasing the maintainability and testability of client code.

The following table compares the responsibilities of M, V, and C under the server and client MVC:

	Model	View	Controller
Server Side	Returns the Domain Objects used to display the page content.	Represents a page abstraction, including page content presentation, data, and event Definitions	Process events triggered on The View, obtain data, update data on the View, and trigger View content rendering.
Client Side	Returns the Restful Services of JSON data.	Same as above	Same as above

Best Practice 2: Application dependency injection and IoC container

The application of the MVC pattern is essentially a decoupling of Abstract Logic responsibilities. Dependency injection and IoC containers are decoupled from the physical dependencies of the Code. Use constructor injection, Set Value injection, interface injection, or IoC container as much as possible to remove direct dependencies between specific implementation classes, naturally, the testability of each specific implementation class can be greatly improved.

Best Practice 3: The application template engine presents the subject content

In an AJAX application, a View that needs to be presented by the client must be rendered with some HTML, which is often dynamically constructed based on the JSON data returned by the Model. Generally, we have three methods to construct and present these HTML:

• Traverse JSON data in JavaScript, splice HTML strings, and render them to the page;
• Traverse JSON data in JavaScript, dynamically instantiate the DOM object, and present the html dom through the DOM object method;
• By binding JSON data to an HTML template using a JavaScript template engine such as JTemplate, the template engine displays the final HTML;

The recommended content of this best practice is for a ViewSubject content, Should be presented through the template engine as much as possible. Why? Because, for a WEB program, the most unstable and frequently changing part is undoubtedly the HTML and CSS of pure graphics. The template engine is used, it will make these HTML as concentrated as possible, easy to modify, and easier to integrate HTML and JavaScript.

Best Practice 4: application Script #

Application Script # The benefits have been mentioned earlier. Here is a simple list:

• Make full use of the existing IDE's comprehensive coding for popular programming languages such as C # source code, especially the support for strong types, refactoring and testing;
• Compared with JavaScript developers who hire Senior with high salaries, Junior C # developers are much cheaper;

If you disagree, please list the reasons why I should not use it?

 

For examples of the above best practices, see my previous article: This is jqMVC #-CNBLOGS Google Tracer Sample.

 

Please fill in the missing and correct me! Thank you!