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.
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?
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.
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.
( and author)
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.
( and author)
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.