I'm trying to be a good dooby and test everything with JUnit. Sometimes I uncover issues while setting up the testing that cause me to alter my thoughts on the design. Part of the project requirements are for us to document our design decisions. I'm starting to think that maybe I should be including the test materials and a junit.jar file, since they have played a fundamental role in the project. Any opinions? Does this seem like a practice that would tick a Sun marker off? (e.g. "why are you including an open source jar with your project; you didn't write that code! And what the heck is all this test stuff doing here in the first place?") Inquiring minds want to know.
I was wondering pretty much the same thing. My plan was to just jar the unit tests and make a reference to in the readme or some other part of the documentation under a clearly marked section, e.g. "Unit Testing Strategy". I didn't plan to include the JUnit file- just a note of the version of JUnit that was used. The idea is to leave a trail of breadcrumbs for future maintenance programmers. I don't see a problem with doing this as it doesn't really affect the actual running of the application by the Sun marker. I could be wrong though. Any comments on this plan?
Wow, I hadn't even thought about including test results. The assignment says "You are not required to develop your code using any particular implementation of the Java 2 platform, but the submission that you return <i>must have been tested and shown to work under a production (not development) version of the Sun Microsystems' Java 2 platform</i>". Is Sun expecting us to send documentation of our testing strategy and our test results?
Reid M. Pinchback
Joined: Jan 25, 2002
Originally posted by Junilu Lacar: I didn't plan to include the JUnit file- just a note of the version of JUnit that was used. The idea is to leave a trail of breadcrumbs for future maintenance programmers. ... Any comments on this plan?
I like this idea. The information is complete. The marker has what he needs, but nothing he doesn't really need. The submission doesn't get bloated by another jar (there was info from Sun when I signed up for this that you should try to keep the uploaded materials below 1 meg).
Originally posted by Robin Underwood:
Is Sun expecting us to send documentation of our testing strategy and our test results?
Well, I don't know what they are expecting, that is the problem. I know when I write requirements documents they are a heck of a lot more specific than what Sun gives us, and I'm inclined to think that is part of the "test". It is a real-world situation to have something that purports to be a requirements document but to have a lot of holes in it. What I did was document all the assumptions I felt I needed to make before beginning the project; essentially applying the philosophy that QA people use - if you've been asked to test something, but don't have a requirements doc, your first job is write a requirements doc.
why are you including an open source jar with your project; you didn't write that code! And what the heck is all this test stuff doing here in the first place?")
Meaning I have seen 155/155 grading and they did not send in test results or a JUnit jar file. If you use JUnit and it helps great, but you don't have to let them know that you used it. And it won't get you extra points for being a good person for using it. Mark
I have the very same question. For me it's not just a matter of excluding my Junit test files. I also a couple of mock objects (and code that calls them(MockDataAccess for example) and lots of acceptance test code as well. I also tested add and remove record and modified invariant() to get more info on deleted records - again, for multithreading testing purposes. Mark, will I be docked for this? Do I need to remove this method and all add record, remove record code? (Even if simply exlcude my unit test files, my code as it stands now, has been slightly modified for testing purposes.)
Sometimes Junit requires that you make a particular method public so I guess that will have to be modified or explained? Also, I have some convenience mehtods for testing only - like "dumpMap" "clearAllLocksNoWait", stuff like that. So I guess the upshot I need to clean up my code and remove all evidence of testing??? Any response would be greatly appreciated. I think, the way I've been trained (XP) - it's an integral part of the code.
Thanks Max, Do you think that I should rip out all my helper methods and even the overridden invariant method in my DataExt class? This method is overriden so I can print out deleted record count. I used this a lot for a couple of multi client acceptance tests. Thanks for any feedback. Melinda
town drunk ( and author)
Joined: Jun 27, 2002
I think so, yes. I'm a big XP proponent myself, but I don't think that the production ready code should any methods that were there only for testing. Without looking @ the code, I wonder if it would be possible to use your toString() for debug message, or maybe even log the deletion of records? All best, M
Well, if you want to test a method, your JUnit test case needs to be able to access that method. This needn't require a public method though, if what you're testing shouldn't really be public. You can make a package-access method, and then make your test case part of the same package. Note that it can be in the same package but a different source tree, so that when you jar up your submission you can eaily omit the test classes whose source is elsewhere. E.g. my directory structure includes src/suncertify/db/Data.java test/suncertify/db/DataTest.java When testing I compile all files in the src tree and test; for my submission I will use only the stuff in src. In general I try to avoid testing any methods not explicitly part of the public API of a class (which for me would include public and protected methods, but usually not package or final) - and for Developer Cert I'm extra inclined to follow this approach since we constantly hear we should keep things simple. But if you do want to put in non-public methods for testing, it's not difficult to do, as shown above.