Ajax Basics Tutorial (6)-6.1 JavaScript questions

Read here, it should be clear, to really good use Ajax, you need to write some JavaScript code. Although frameworks and toolkits can lighten some of the burden, you may end up with more JavaScript code than usual. Because we wrote a lot of ourselves, it's not easy to write JavaScript code, but in this chapter we still have to put a few stones on your exhausted shoulders.

Specifically, we'll introduce test-driven development (Test-driven DEVELOPMENT,TDD) and show you how to apply TDD when developing JavaScript code. Although this approach doesn't solve all your programming problems right away, it can at least help you get your work done as quickly as possible and go home for dinner with your family on time. Let's start with a brief introduction to TDD and the widely used junit. After a good foundation, we'll discuss jsunit and how to write and run tests.

6.1 JavaScript questions to ask

If you've been involved in Web application development, you may have written some JavaScript code; Of course, if you're just writing some of the simplest functions, then it might not be a good idea for JavaScript. Browsers are incompatible, lack of good development tools, no productivity tools such as code completion, no debugging tools-so many drawbacks that most developers are more willing to use vi[1].

We are well aware of your difficulties. In the 5th chapter, many tools have been discussed that will make your day easier. This chapter will show you how to make developing JavaScript as easy as possible (at least, until the tool developers catch up, this approach is appropriate [2]). Using a test-first (Test-first) method to write JavaScript can greatly simplify the entire development process.

Introduction to 6.1.1 test method

Yes, surely some readers will say this: "I only write tests before the product is issued." "Some people may chuckle about the quality Assurance department. Others, as project managers, may be more likely to say: "We don't waste time writing test code; We have to write real code." "So what does it mean to use TDD anyway?"

TDD is generated by agile development campaigns, especially extreme programming (extreme PROGRAMMING,XP), and TDD is a core tenet of XP. TDD advocates believe that writing tests should not be done after development, which is usually just "hindsight," rather than writing the test before writing the code. Testing is essentially about designing a document, rather than spending a lot of time fiddling with a complex graphical tool, you want to "draw" a class directly into your code. Start by writing tests for some small blocks of functionality. In some languages, the tests you write do not even compile, because the referenced class does not yet exist. Once you have established the test, you can run the test (of course, the test will fail to run at this time). Then write the smallest amount of code so that the test passes. Next, refactor the code and add more tests.

You can often use a test framework to help you write automated tests. The most famous framework is JUnit, but now there are many xunit projects that can simplify the creation of tests in various languages. Generally, these frameworks are based on assertions (assert). The developer writes a test method that compares the actual results of the calling method with the expected results. Of course, you can manually check a log file or user interface to complete these comparisons, but it's not only faster and more accurate to use your computer to complete the data. In addition, even if you let the computer run the same test 1500 times, they will not wearies, if people can not do this.

With JUnit and other test frameworks, writing and running tests has become quite straightforward. This encourages developers to create a large number of tests (which tend to cover a variety of test situations more fully) and is happy to run them frequently (faster to help developers find bugs). In many cases, if TDD is used in a project, the test code is often as much as the production code!

Using TDD can bring many important benefits:

Provide clear goals: you know that once it's over (i.e. once the test passes), your work is done (assuming your tests are well written). The test will create a natural boundary for your code, allowing you to focus on the current task. Once the test passes, there is clear evidence that your code works. Running automated tests in a xunit framework is faster than a few orders of magnitude relative to manually testing the user interface or comparing the results in a log file. Most xunit tests run in just a few microseconds, and most people who use TDD run several tests a day. In many development teams, code must successfully pass the test before it is checked into the source tree.

Provides documentation. Do you often run into code that you can't read? The code may not have any documentation, and the person who is developing the code may have gone (or been on vacation) long ago. Of course, the time to see this kind of code is often very outdated, it may be 3 o'clock in the morning, there may be a vice-president beside you loudly urged to solve yesterday's problem, so it is more difficult to spend some time to understand the original author's intentions. We've seen some good unit test documents that indicate what the system is going to do. Testing is like the mark left by the original developer to show how their class works.

Improved design: Writing tests can improve design. Testing helps you think from an interface perspective, and the test framework is also the customer of the code. Tests can make it easier for you to think. If you do follow the principle of "as simple and effective as possible," you won't be able to write a few pages of complex algorithms. The code to be tested is usually less dependent and not closely related to each other because it is easier to test. Of course, there is an additional role, it will be easier to modify it!

Encourage refactoring: With a robust set of tests, you can refactor as needed. Do you often encounter some code that you don't know whether or not to modify? All these worries make you slow and conservative, because you can't guarantee that the changes will break the system. If you have a good set of unit tests, you can refactor with confidence, while ensuring your code remains concise.

Increase speed: Does writing so many tests slow down the pace of development? People often use speed (or development overhead) as a reason to object to TDD and using the Xunit framework. All new tools have learning curves, but when developers adapt to the framework they choose (usually in a very short time), the development speed actually accelerates. A complete unit test set provides a way to perform regression testing on the system, which means that after adding a new feature, you don't have to worry about whether it will break the original system or not.

Provide feedback: Unit testing also has a often overlooked advantage, that is, the pace of development. It doesn't seem to matter, but after you pass the test you will have a sense of achievement to accomplish the task! You don't change your code all day long without any feedback, and this test-code-test method encourages you to move a little bit, usually with only a few minutes to modify the code. This way you won't see a whole bunch of new features popping up all at once, but just let the code base move one step at a time.

From our experience, testing can be contagious and you may become addicted to it. At first, many developers were skeptical, but eventually almost every developer was hooked on the green stripe [3] After the test was run. Testing the first "catch" bug or add a new feature, just a few minutes rather than a few hours, is often at a time when developers will be delighted to realize that the test is really meaningful.