permaculture playing cards*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes JUnit:  How to test read/write file Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "JUnit:  How to test read/write file" Watch "JUnit:  How to test read/write file" New topic
Author

JUnit: How to test read/write file

Peter Yunguang Qiu
Ranch Hand

Joined: Nov 22, 2003
Posts: 99
I am new to JUnit, How to use it to test db access parogram which mainly reading and wirteing files?
Thanks for help.


Peter
Hans ter Wal
Greenhorn

Joined: Oct 01, 2003
Posts: 12
Hi Peter,

JUnit is a great tool!
If recently started with it so if I'm saying something wrong please correct me anyone.
How I implemented in my project is to create to src's directorie ie.
project-->code-->suncertify-->db
project-->Test-->suncertify-->db
In creating a new source directory you seperate testing code with the code you're going to submit to sun. The package names are the same so that you can access classes as if they where in the same directory.
Now on for the good stuff.
There are different ways to use JUnit, the following is one of the options JUnit offers.
In the testing package "project-->Test-->suncertify-->db" you create a class that that extends junit.framework.TestCase.
All the test cases you want to create must have a public modifier and return void and last but not least should start with 'test'.
public void testReadFirstRecord() {}
So how do you test if something is amiss. Every test case has an expected result for example, testReadFirstRecord() should get the first db record.
The assertEquals(String expect, String result) method checks to see is the data you requested is the same as you expected. The method returns a boolean that the junit framework uses to determine if the testcase succeeded or not.
the setUp() and tearDown() method are used before and after every single test case method in the testCase class. For testing the data class it's very important that you use an 'fresh' db file. If you don't one of you're methods can corrupt the file you working on and well you get the idea;-)
Here some of the code I use



SCJP & SCWCD
Derek Canaan
Ranch Hand

Joined: Nov 05, 2003
Posts: 64
Hi Hans,
Thanks for sharing. Could you also share how you use junit to test concurrent read-read, and read-write?
Thanks in advance,
Derek
Peter Yunguang Qiu
Ranch Hand

Joined: Nov 22, 2003
Posts: 99
Thanks Hans.
In my DB access file, I just used RandamAccessFile. I think it is easier than use many stream classes. What do you think of it?
Peter Yunguang Qiu
Ranch Hand

Joined: Nov 22, 2003
Posts: 99
Hi, Hans:
Using JUnit, it seems need more work than directly test. I just print out the record that been readed, and see by my eyes. It seems simpler and need less work.
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
Peter,
At first it does seem simpler to just print, but really using JUnit provides lots of benefits. It allows you to automate entire sets of tests (I used Ant for the automation scripting). If you put a lot of thought into the tests, and execute them whenever you make a change, you can be fearless that when making subsequent modifications or design changes to your code, that you haven't broken anything that you've already got working correctly. In the long run, it's a lot easier than manually checking the results of lots of print statements and possibly not catching your errors until they cascade into a big mess. If you consistently follow this practice, you will feel a lot more confident in the correctness of your work, particularly when it comes time to submit the assignment or later deliver code to customers.
Taking it to another level is a practice known as "test-driven" development. In this methodology, you actually write tests first before writing the code. It works like this:
Basically, you think of something your code needs to do (a use case), write a test that proves that a single aspect of your code is correct, and then write the code that passes the test. You keep doing this one little test at a time until you can't think of any more tests. Your tests act as a client (and extra documentation) for your code. This is a truly elegant way to drive a concise design out of a set of use cases or requirements.
Although I did use Junit testing religiously while implementing my assignment, I didn't use "test-driven development". I wish I had though because I probably would have finished a lot sooner. I have since then become "test-infected" and am very reluctant to write ANY code before writing a test for it.
For good reading material on "test-driven" development", read:
Test-Driven Development by Kent Beck
Agile Software Development by Robert C. Martin
"Uncle Bob" Martin's book, besides being a superb manual for O-O design, has a particularly lucid example that shows the process in action where 2 programmers sit down and write some code to score a game of bowling. I had the good fortune to actually see this done in person as Uncle Bob gave a live demonstration of the bowling game development at a meeting of our local Java Users Group. It took me a while to wrap my mind around this process but I am now totally and permanently hooked and will not go back.


kktec<br />SCJP, SCWCD, SCJD<br />"What we observe is not nature itself, but nature exposed to our method of questioning." - Werner Heisenberg
Hans ter Wal
Greenhorn

Joined: Oct 01, 2003
Posts: 12
Originally posted by Derek Canaan:
Hi Hans,
Thanks for sharing. Could you also share how you use junit to test concurrent read-read, and read-write?
Thanks in advance,
Derek

Hi Derek,
I'm sorry to say that i'm not that far along in my assigment to be of any assistance, if got some ideas as how to but I not sure myself and I don't want to send you in the wrong direction.
Look at Junit for some more info
http://www.junit.org

Regards

Hans
Hans ter Wal
Greenhorn

Joined: Oct 01, 2003
Posts: 12
Originally posted by Peter Yunguang Qiu:
Thanks Hans.
In my DB access file, I just used RandamAccessFile. I think it is easier than use many stream classes. What do you think of it?

Hi Peter,
Like you I've just started with the assignment (urlybird 1.3.2), what I've done I first brewed some coffee and put in some long nights just to go through this forum and look at common problems that everyone has/is faced/facing during completion of the assigment.
For example the usage of a randomaccess file, is one of the or more likely the most used solution for db access. Some people cache it some don't (including me). Why? Because I like to keep things simple, I might change my mind in the future but for now no caching.
Hi, Hans:
Using JUnit, it seems need more work than directly test. I just print out the record that been readed, and see by my eyes. It seems simpler and need less work.
Peter

This is my first JUnit project and with the testing of the data section i've reaked the benefits (made some mistakes that where easy to mis with simple print statements). If you like to put in print statements thats fine, but it clutters you're code, junit provides a graphic framework that shows you if you're tests succeed or fail. (Green is good and red is Evil) and can be completely seperated with the you're going to submit.
I use Eclipse as my IDE and it comes with JUnit, development could not be easier (except if someone else did it for you ;-) ).
Try www.junit.org there are some tutorials there and www.eclipse.org for the IDE.

Well it's back to work for me

Regards,

Hans
Peter Yunguang Qiu
Ranch Hand

Joined: Nov 22, 2003
Posts: 99
Thank Hans, Thanks Ken, and Thank all people who help me. I will try to get used to using JUnit to test my code.
Peter Yunguang Qiu
Ranch Hand

Joined: Nov 22, 2003
Posts: 99
Hi, Hans:
I read your post and code carefully today. I learned a lot. Thank you very much for you help. :roll:
Peter Yunguang Qiu
Ranch Hand

Joined: Nov 22, 2003
Posts: 99
Hi,kktec,
Thank you very much for you help.
Taking it to another level is a practice known as "test-driven" development. In this methodology, you actually write tests first before writing the code.

I think most people are not customed to "test-driven" thinking. What do u think?
Ken Krebs
Ranch Hand

Joined: Nov 27, 2002
Posts: 451
Peter,
I think you are correct and it is not the usual way to think about design.
For me, after watching Uncle Bob in action, I just started doing it and quickly came to realize that it really helps because it gets you immediately thinking about what's truly important about any class/program you design, its BEHAVIOR. When I first started with O-O design I would look at commonality in the data area for clues on how to structure the design but I eventually found that this can be misleading. Writing tests first puts your focus where it ought to be, on behavior. Your tests are actually clients of the class being tested. By doing it in baby steps you just sort of drive the design out of your use cases. What you end up with is a design that is concise and without all the extra baggage of unused functionality that hampers further extension of the design. It's really quite amazing to see how it works in practice. As added bonuses, you get more reliable software that you can boldy continue to improve without fear of breakage and the tests act proof that it still works and as extra documentation about how a client is to use your class.
BTW, JUnit was written by Kent Beck, the author I previously mentioned, and Erich Gamma, one of the noted co-authors of the famous Gang-of-Four "Design Patterns" book and also one of the driving forces behind the Eclipse IDE.
I thank these 2 engineers and the people who influenced their work for giving us this wonderful bit of software. There have been many derivatives made for other purposes including HttpUnit for testing web interface acceptance testing, CPPUnit for C++, and even VBUnit for Visual Basic, and others besides.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JUnit: How to test read/write file