Code Clean Way 108 109 page missing translation

"Code neat Way" Chinese electronic version less than two pages I help translate it for reference only the wrong place more criticism

By clearly like the month QQ 605283073

English version of Chinese ebook

360 Network disk: Http://yunpan.cn/c3ISX4cRsqcMU access password 67b9

Our interests.

This half is in order to connect with the previous page. But not particularly fluent. The last sentence of this paragraph is re-translated:

It's not our job to test third-party code, but it's best for us to write test code for our third-party code.

If we don't know how to use our third-party library. It may take us a day or two days (or even longer) to read its documentation to understand how to use it. We then use the third-party code to write our code and determine whether it is executed as we intended. It's no surprise that we're stuck trying to figure out whether a bug is a lengthy debug order from our code or a third-party code.

Learning third-party code is not easy. It's also hard to integrate third-party code. Learning at the same time and integration of code is more difficult to double. If we were to do something differently. Instead of experimenting and trying to add new things to our product code, write tests to deepen our understanding of third-party code. Jim Newkirk called the test a learning test.

Because we want to use third-party libraries in our applications, we call third parties (libraries) as APIs in our learning tests. We are essentially validating our understanding of the API through controllable experimentation. The experiment focused on my needs beyond the API itself.

8.3 Learning log4j

Rather than customizing our own loggers, we prefer to use Apache's log4j package. We download the log4j package and open the documentation page for its introductory features. Without fully reading the document, we wrote the first test case, expecting it to write the word "Hello" to the console.

@Test public
voidtestlogcreate () {
Logger Logger =logger.getlogger ("MyLogger");
Logger.info ("Hello");
}

When you run it, the logger generates an error that prompts us for something called Appender (log destination). Reading the document a little bit, we found a class called Consoleappender. So let's create a consoleappender to see if this has unlocked the secret of input to the console.

@Test public
Voidtestlogaddappender () {
Logger Logger =logger.getlogger ("MyLogger");
Consoleappender appender= new Consoleappender ();
Logger.addappender (Appender);
Logger.info ("Hello");
}

This time we find that Appender does not have an output stream. Strangely-logically it should have an output stream just right. After a search on Google, we tried to make the following changes to the code:

@Test public
Voidtestlogaddappender () {
Logger Logger =logger.getlogger ("MyLogger");
Logger.removeallappenders ();
Logger.addappender (Newconsoleappender (
newpatternlayout ("%p%t%m%n"),
consoleappender.system_out));
Logger.info ("Hello");}

The problem was fixed, and a log message containing "Hello" appeared in the console. It seems strange that we have to tell Consoleappender to let it write to the console.

Interestingly, when we remove the consoleappender.systemout parameter, "Hello" can still print

Come out. But when we remove the Patternlayout (formatted layout), it still prompts us for the missing output stream. This is very strange.

If we read the document more carefully, we will find that the default Consoleappender constructor is "Not configured (output stream)", but this is not conspicuous and does not benefit. In log4j, this is more like a bug or at least contradictory.

With more Google searches and reading documents and tests, we end up with a listing of 8-1 code to close this example.

We've got some idea of how log4j works. We present this part of the knowledge in a simple unit test set.

Listing 8-1 Logtest.java

public class Logtest { private Logger Logger; @Before public Void Initialize () { logger = Logger.getlogger ("logger"); Logger.removeallappenders (); Logger.getrootlogger (). Removeallappenders (); } @Test public void Basiclogger () { basicconfigurator.configure (); Logger.info ("Basiclogger"); } @Test public void Addappenderwithstream () { logger.addappender (new Consoleappender ( new Patternlayout ("%p%t%m%n"), consoleappender.system_out)); Logger.info ("Addappenderwithstream"); } @Test public void Addappenderwithoutstream () { logger.addappender (new Consoleappender ( new Patternlayout ("%p%t%m%n")); Logger.info ("Addappenderwithoutstream"); } }

Now that we know how to initialize a simple console log output, we can encapsulate it in our own log output so that other parts of the application can be isolated from the log4j boundary interface.