Remote Unit Testing Milestone III Alex Riordan Brian Pruitt-Goddard

Brief Recap Develop an application with the capability to create, edit, open, compile, and execute small source files through an interface on the Android phone, with a particular focus on remote unit testing. Application requires you to install: o Server application for the execution, compilation, and physical management of files. o Client application for the creation, editing, downloading, and uploading of files.

Final Requirements: Client I/O Capabilities o Open an existing file on either the server, or from another external source such as an SD card. o Saving a file either to the server or to another external storage device. o Creating a new file. o Editing a text file.

Final Requirements: Client Issuing Commands to the Server o Save this file to the server. o Delete this file from the server. o Upload this file to me. o Compile this file. o Execute [run a unit test] this file. o Change this server configuration option.

Testing Strategy: Client “On the fly” testing o Lower-level I/O functionalities are tested “on-the-fly.” o Ensure that data sent to the server is not corrupted; furthermore, that the server receives the data as expected. Long-term testing o Ensure that all the components “fit” together and return desired results. o Since Brian is developing the client-side, Alex will test aspects not solely dependent on the server-side.

Final Requirements: Server I/O Capabilities o Physically saving/removing files to hard disk, as requested. o Delivering existing files to the client, as requested. Just following orders... o Compile a file with appropriate options. Log all results. Return relevant results to client. o Execute a file with appropriate options. Log all results. Return relevant results to client. o Reading and understanding a configuration file.

Testing Strategy: Server “On-the-fly testing” o Ensure that server can compile any valid Java source file (.class files) o Ensure that any valid unit test will be run and return a result. Long-term testing o Since Alex is writing the server-side, Brian will test the server-side by blinding feeding it multiple.class files to compile and to run unit tests against and comparing not only the results, but if the requested results and no less were returned.

General Requirements Performance: o “Don't leave me hanging, man”: Remotely executing a file and waiting on output always leaves the possibility of an infinitely looping program. We can't decide the halting problem, but we can decide that a program running 100 times longer than its expected run time probably isn't working and should be terminated. o Responsiveness: Any text editor should be responsive! Security: o You should not just be able to let just any IP tell the server what to do. It needs credentials.

The Devil is in the details... How the heck are we doing any of this?? o Remote procedure calls: XML-RPC o Compilation: javac [Java compiler] o Unit testing: Junit o File I/O: Java standard library Ok, so how do those work?

Compiling We make the assumption that (a) Java is installed and (b) the Java compiler (javac) exists. The compile process o Client sends a request to the server: Compile this file with these settings and return to me these results. XML-RPC packages this all up and sends this package of data the server's way. o Server opens up this package and follows the instructions – it puts together the necessary arguments and commands before making a call to the java compiler to do the actual compiling.

Compiling Cont. Wait, what? Process p = Runtime.getRuntime().exec(cmdarray, envparray); o Basically, based upon the information sent to us by the server, we build the variables cmdarray and envparray (Commands and Environment variables arrays) and then spawn a new process (the java compiler specifically) which will behave differently depending on what's in the cmdarray and envparray.

How to Run a Unit Test If you plan on compiling unit test source files, then some Junit library needs to be available. That is the most basic assumption. The unit testing process o Junit provides its library for programmatic use. No need to make external calls to compilers for this. o Call the static method UnitTester.test(List_of_Classes, Formatting_Options) o Get results.

Unit Testing Cont. So, what happens when I call UnitTester.test()? o Well, first you need to pass it a valid Class object, an Object in Java which describes a class. But if you just received the class file from over the server, how could the Java VM possibly have loaded that class file? Simple solution: use dynamic class-loading. Implementation-wise, we have chosen to use a URLClassLoader to make sure a valid Class object(s) is passed to the UnitTester.test() method. o Next, call JunitCore.run(List_of_Classes) which will return a Result object. o Using the Formatting_Options variable, determine which parts of the Result object you want and how you want to format them.

What's done, what needs to be done What's done, at least partially o Running a unit test remotely o Formatting unit test output o Data serialization: partial o Text editor: partial o File chooser What needs to be done o Compiling a file remotely o File I/O at server, client-side o Parsing the configuration file o Error handling