Transcript How to Run a Unit Test

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:
Server application for the execution, compilation, and
physical management of files.
o Client application for the creation, editing,
downloading, and uploading of files.
o
Final Requirements: Client
• I/O Capabilities
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.
o
Final Requirements: Client
• Issuing Commands to the Server
o
o
o
o
o
o
Save this file to the server.
Delete this file from the server.
Upload this file to me.
Compile this file.
Execute [run a unit test] this file.
Change this server configuration option.
Testing Strategy: Client
• “On the fly” testing
o
o
Lower-level I/O functionalities are tested “on-the-fly.”
Ensure that data sent to the server is not corrupted;
furthermore, that the server receives the data as
expected.
• Long-term testing
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.
o
Final Requirements: Server
• I/O Capabilities
Physically saving/removing files to hard disk, as
requested.
o Delivering existing files to the client, as requested.
o
• Just following orders...
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.
o
Testing Strategy: Server
• “On-the-fly testing”
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.
o
• 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:
“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!
o
• 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
o
o
o
Remote procedure calls: XML-RPC
Compilation: javac [Java compiler]
Unit testing: Junit
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
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.
o
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
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.
o
Unit Testing Cont.
• So, what happens when I call UnitTester.test()?
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.
o
What's done, what needs to be
done
• What's done, at least partially
o
o
o
o
o
Running a unit test remotely
Formatting unit test output
Data serialization: partial
Text editor: partial
File chooser
• What needs to be done
o
o
o
o
Compiling a file remotely
File I/O at server, client-side
Parsing the configuration file
Error handling