Today, I started beefing up the standard JUnit tests in RODSAdai... and remembered that a LOT more code is needed to run OGSA-DAI implementing clients than to just build it.
So, since the new test code runs an OGSA-DAI test... I am having a lot of attempts at "mvn compile", a test error or failure will result, so I check the log, find the class it needs, and make a reference to it, installing it in the maven repository if it was not in the global one, and repeating.
This will probably consume me tomorrow and maybe a bit of friday. I mean it when I say a lot of jars.
Showing posts with label JUnit. Show all posts
Showing posts with label JUnit. Show all posts
Wednesday, June 25, 2008
Monday, June 9, 2008
JUnit and Use Cases
Today I spent some time researching how JUnit works (JUnit is the preferred testing framework of maven, which is nice, considering that whenever you build to deploy, it will run the test cases and let you know if something you adjusted or refactored broke).
The next thing I did was to start drawing out the application by the top-level use cases (the use cases will derive test cases which will derive code). The apps I build for the RODS interface will basically be an extension of OGSA-DAI's discovery and query algorythms. A server list stored in a properties file (which can later be upgraded to a database of some sort) will be used to pull up the appropriate server (by key) and the default Ogsa-Dai data resource to hit on that server... the query gets passed on, and then the specialized class structure gets returned.
Now I am thinking of the smaller cases and how all the classes will break out around each other. After that I'll start actually modifying OGSA-DAI example classes and writing wrapper classes and interfaces (and their test cases). Right now I just want to get it all on paper so I have a good reference for which peice I am working on and where it fits.
The next thing I did was to start drawing out the application by the top-level use cases (the use cases will derive test cases which will derive code). The apps I build for the RODS interface will basically be an extension of OGSA-DAI's discovery and query algorythms. A server list stored in a properties file (which can later be upgraded to a database of some sort) will be used to pull up the appropriate server (by key) and the default Ogsa-Dai data resource to hit on that server... the query gets passed on, and then the specialized class structure gets returned.
Now I am thinking of the smaller cases and how all the classes will break out around each other. After that I'll start actually modifying OGSA-DAI example classes and writing wrapper classes and interfaces (and their test cases). Right now I just want to get it all on paper so I have a good reference for which peice I am working on and where it fits.
Subscribe to:
Posts (Atom)