This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
i passed, finally ;-) B&S, 372 / 400 ...not too bad...
a huge, really, a huuuuuge thanks to andrew. without you this would not have been possible, you are keeping this forum alive and on a constant level.
that's what sun wrote:
This report shows the total number of points awarded for each section. The maximum number of points is 400, to pass you need a score of 320. Section Summary: Section Max Actual Points Points General Con: 100 90 Documentation: 70 65 OOD: 30 30 GUI: 40 27 Locking: 80 80 Data Store: 40 40 Network Server: 40 40 Total: 400 372
i'm not a native speaker, and i wrote all documents in the last nights before submission. this probably explains the losses in the first sections. don't know what is wrong with my GUI, it's not fancy, but functional. i would have given me full points ;-)
what else to say?
i used java 1.4, for the simple reason that i already had a bunch of code written when java 5 came across (my way). my IDE is intellij idea, which i consider the best IDE i know.
ant automized a lot of build tasks, at the end i also used it to build the final submission jar. i found that very convenient to ensure error safety in the middle of the last night.
i'm using checkstyle with pretty tough settings to enforce coding conventions and to avoid certain mistakes (forgotten javadoc, ...)
findbugs found a load of errors. okay, not a load, but a couple of serious problems ;-)
i had to use java.logging over log4j, but found it pretty okay. i left all logging comments in the code.
for the data layer and helper classes, i used unit tests extensivly. i thought about using it for the GUI as well, but figured out that this was too much work.
and last but not least: i worked hard to build a clean and well structured oo design. i used design rules and patterns as often as possible. "head first design patterns" is a great book, i really, really learned a lot about good design. i also spoke a lot with colleagues, discussing (abstracted) problems and design options for a possible solution.
any questions welcomed, and if anyone else should want to take the chance to thank andrew, a posting here would be an opportunity... :-)))
Hi! A big congrats to your recent success on the SCJD! My question is how exactly did u go by doing Unit tests for your data.java!I have been trying to understand JUnit for a while now and how i could relate it to the SCJD! Useful links/tips would be appreciated! Thanks! [ December 16, 2005: Message edited by: Saheed Adepoju ]
it's pretty straightforward to bring unit testing into your application, not a big deal at all.
from a bird's view:
- identify the unit you want to test. say the Data.lock() method. - create a unit-test in the same package (but usually in a different source tree, say you have src/mypackage/Data and testsrc/mypackage/DataTest) - extend TestCase & write some testcode. note that the method name has to start with test*
usually your IDE should have some build functionality to run unit-tests, otherwise use the ant task <junit> for it.
hope it helps, jan
author and jackaroo
I would generally recommend starting your unit testing with some other method other than the lock method, for the simple reason that the lock method has to work in multiple threads (which can add complications). You can do basic tests on the lock method in a single threaded environment, but sooner or later you will have to add multi threading into your tests.
So I would suggest starting with something a bit simpler - perhaps the read() method. Maybe your first test could be to read the second record from the database - compare the values you get back with the values that you believe you should have gotten back.
Later you can add more tests - perhaps try to read record number -1. Or try to read record number 100 - do you get the errors you expect? Delete a record and try and read it - again, do you get the error you expect? Try boundary conditions (e.g. record # 0, or the last record in the database).
As for testing threads / performance testing, you might be interested in this thread when you feel up to it.
author and jackaroo