Displaying keyword search results 1 - 4
Created by freyo on September 07, 2011 16:46:14 Last update: September 07, 2011 19:23:00
The Android unit test framework is based on JUnit 3 , not JUnit 4. Test cases have to extend junit.framework.TestCase or a subclass (such as android.test.InstrumentationTestCase ). Tests are identified by public methods whose name starts with test , not methods annotated with @Test (as in JUnit 4). An Android test suite is packaged as an APK, just like the application being tested. To create a test package, first you need to identify the application package it is testing. Google suggests to put the test package source in a directory named tests/ alongside the src/ directory of the main application. At runtime, Android instrumentation loads both the test package and the application under test into the same process. Therefore, the tests can invoke methods on...
Created by Dr. Xi on March 02, 2011 11:39:18 Last update: March 09, 2011 12:19:30
Some peculiarities about Java PrintWriter: PrintWriter never throws any exceptions. From JavaDoc : Methods in this class never throw I/O exceptions, although some of its constructors may. The client may inquire as to whether any errors have occurred by invoking checkError(). When error occurs, you'll never know anything more than that it occured, because checkError returns boolean. When a character is out of the range of the character encoding of the PrintWriter, it prints a question mark (?). But this is not an error. Test code:
import java.io.*; public class TestPrintWri...Latin1 test result:
java TestPrintWriter iso-8859-1 | od -bc 000000...UTF-8 test result:
java TestPrintWriter utf-8 | od -bc 0000000 141...Also, the constructor throws a FileNotFoundException when you try to write to a...
Created by Dr. Xi on October 06, 2008 23:31:56 Last update: October 06, 2008 23:35:08
Use file.write instead of print .
Python 2.5.1 (r251:54863, Mar 7 2008, 04:10:12) ...
Created by Dr. Xi on October 06, 2008 22:48:08 Last update: October 06, 2008 22:50:11
A first attempt would be to create an input file like this:
userid password shell_command1 shell_...and feed the lines to the telnet client:
cat telnet_input.txt | telnet remote_host #...However, you'll learn soon enough that it doesn't work. You get output like this:
Trying 192.168.159.128... Connected to bash...What's happening? The telnet client depleted all input before the remote host had a chance to respond. Since there's no more input, the telnet client initiated to close the connection. Adding a delay between the commands makes it work:
(echo userid sleep 10 echo password ...How much time to sleep between commands is just guesswork. You can use Expect to provide more control over the automated session:
#!/usr/bin/expect # timeout script aft......