Displaying keyword search results 1 - 5
Created by freyo on September 09, 2011 11:43:36 Last update: September 09, 2011 11:45:45
When you run automated Android tests with Eclipse or from the command line, you get text output, which isn't good for reporting purposes. If you run a large set of test cases with automated build, the text report isn't very helpful. Fortunately, Android CTS generates test reports in XML with accompanying XSL to make it look nice in a browser. To run your own tests with Android CTS: Download Android CTS Make a new directory MyRepository under android-cts , alongside the existing repository directory. Copy host_config.xml from repository to MyRepository Create directory plans under MyRepository , add a test plan ( MyTests.xml ):
<?xml version="1.0" encoding="UTF-8"?> <TestPla...Create directory testcases under MyRepository . Copy TestDeviceSetup.apk from repository/testcases to MyRepository/testcases Under MyRepository/testcases , create a test...
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 February 17, 2011 16:09:49 Last update: February 17, 2011 16:09:49
This is a common problem with shell scripts running from cron. Everything works perfectly fine from the command prompt, but fails when running from cron. In the worst cases, the job fails silently, even giving a return code of 0! Usually, these are caused by differences between the execution environments: the interactive shell (command line) has more environment variables defined/exported (through .kshrc , .bashrc etc.) than the shell started by cron. A simple way to resolve the differences is to run set in the command prompt and compare the output with the output of set from cron (add a single line to the shell script). You can also make the shell script more verbose by adding the -x switch:
Created by Bambi on August 07, 2009 03:47:56 Last update: August 07, 2009 03:59:15
package hello.world; // package declaration, must ...Compile/Run:
C:\tmp>javac hello\world\HelloWorld.java C:\tmp...Since the class is not public (package access), the name of the Java file could be anything! If a package access class has a public static void main(String) method, it may still be run from the command line using the class name.
C:\tmp>copy hello\world\HelloWorld.java hello\worl...
Created by Dr. Xi on July 29, 2009 20:58:51 Last update: July 29, 2009 20:58:51
UPDATE events set JSCODE = 'var a = 1; var ...