Crossing boundaries: Testing in an integration framework, part 1th

Catch bugs

I remember the first time I got a bug that was automatically tested. At a conference, after I finished my speech called bitter Java, Mike Clark (the automated test master of the Java community, the author of the Performance Tuning tool JUnitPerf (see Resources), now a Ruby on Rails expert) approached me. Mike told me that there is a way to improve my presentation through automated testing. During the remainder of the conference, I followed him around and saw as many of his test sessions as I could see. I started using the technology he recommended and became addicted to turning red strips (which represent test failures) into green strips (which represent test passes). Automatic testing has changed the way I think about software development.

The Java community absolutely has bugs that are automatically tested. Frankly speaking, we have no choice. Competitive pressures have forced many companies to write more and more code, while testers are becoming less and more productive for each developer. Without automated testing, fewer tests will be available and less testing is not a viable option in the face of the growing complexity of modern applications.

Over the past decade, we have seen research on testing tools and technologies. Both JUnit and TestNG are excellent tools to support automated unit testing and are driven by day-to-day developers. Selenium is a tool for improving integration and functional testing. A new development process called agile technology tells people to pay more attention to automated testing and not rely too much on formal design tools as the only tool to improve quality. The Java community has come a long way. (See Resources For additional information on the tools and techniques discussed here.) )

Other programming communities also have bug tools, some of which have more automated tests than Java developers, and they have different reasons for using automated Test experience:

Smalltalk programmers have been using automated tests for almost 30 years, so some of the technologies used in dynamically typed languages are more advanced.

The advantage of the developer of the integration framework is understanding the structure and composition of the framework elements. Some frameworks, such as Ruby on Rails, can generate test cases and provide test features by default.

Languages with Advanced metaprogramming (metaprogramming) capabilities, such as Ruby and Lisp, allow some test techniques that are not supported in other languages, such as easier access to mock objects.

In this and the next article, you will have a complete understanding of the testing methods in the Ruby on Rails integrated development framework. Part 1th focuses on testing model objects and provides some of the policies that are inspired by Rails that can be used to make Java unit tests more efficient. The 2nd part spends more time on functional testing and integration testing. As a Java programmer, you may be familiar with some concepts, especially when testing, while other concepts can broaden your understanding.

Fill gaps

In the previous issue of this series, you learned that dynamic typing brings some types of bugs, which are caught at compile time by statically typed languages. The Ruby snippet in Listing 1 contains four different bugs, which are not exposed until run time:

Listing 1. Ruby Code with Bugs

position = "2"　　　　　　　 #string, where a number was intended
position = positoin + 4　　　#position is misspelled, evaluates to 0
puts "The position is:" +
　　　 position.to_string　　 #The method should be to_s

If the compiler can catch bugs, such bugs are a piece of cake, but if you rely on interpreters, it's much more difficult to manage them. To handle these subtle errors, users of dynamic languages have long relied on automated testing. When testing, dynamic languages and their integrated environments have significant advantages in both general and special sense:

Language is more concise. Tests are basically scripting, and many of the best scripting languages are dynamically typed.

Integrated environment-supported assumptions can make integration testing easier or more powerful. You'll see some examples in the Rails environment.

Dynamic languages allow for looser coupling, making some test formats easier to implement.

After understanding why dynamic language developers are so enthusiastic about testing, it is time to build an actual application that requires some real testing.