Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (499)
Games in Android Showcase (118)
games submitted by our members
Games in WIP (567)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Junit?  (Read 3838 times)
0 Members and 1 Guest are viewing this topic.
Offline Breakfast

Senior Member




for great justice!


« Posted 2003-10-30 12:27:17 »

I've been using java for a while now but I've never really got into JUnit.

Is it worth doing, and if so, where can I find the best  getting started type documentation or tutorials?
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #1 - Posted 2003-10-30 13:07:27 »

I'm starting unit testing with JUnit myself and I can say it's fun! Maybe its due to the fact that the software I'm working on in itself is boring ....

I didn't use any tutorials, just looked up some samples. It's fairly easy.


HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline dsellars

Junior Member




Need to write more games


« Reply #2 - Posted 2003-10-30 13:34:47 »

I've been wondering myself if people round here use it much.

From what I've read of it it seens a really good idea, but in practice the stuff I do at home is in such a state of flux that I feel I'm writing tests and not code all the time.  It's almost like you need a certain level of stability to build upon before you get the benifit from unit tests.

I still feel it should be a good idea though.  A good argument for using JUnit is in Martin Fowlers Refactoring book (which is well worth reading).

What is the general concencus here for JUnit? (both for home projects and professional)

Dan.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #3 - Posted 2003-10-30 14:12:47 »

I have also wanted to use JUnit for my projects... but I find it VERY difficult.

writing tests for trivial methods is easy.  All examples I have seen are trivial.  How do you test REAL CODE?  I asked this on the JUnit mailing list.."how to get started"  they said just dive in and go for it....  I have trouble with that.  It turns out that anything I want to do needs tests that are at least as complex or more complex than the code they are testing and thus my chance for bugs in the tests is huge..  the debugging effort at least initially is more than doubled... there should be some payoff for maintenance changes.. but if changes require changes in the tests then I'm back to doing a lot more work with more chances for errors.

The concept seems sound.. but I just can't figure out how to apply it without my development slowing to a crawl.

If anyone has a solution to that problem I want to hear it.. because I want the unit tests in place so I can be more confident of my refactorings and such.

Offline abies

Senior Member





« Reply #4 - Posted 2003-10-30 14:39:31 »

First - it is normal that good test routine needs more work/code than code it test. It is also normal that you will make bugs while creating unit test. But, if you hit some error, you pay more attention to it and then decide which piece of puzzle is wrong - implementation, your unit test, or maybe documentation you misunderstood.

One of the tricks I use to write good unit tests is to start with basics and then introduce deliberate mistakes (as small as possible) into class code. If they go undetected, add it to your unit test. This works good for reusable middleware classes, I have not used it for classes at end of food chain - I'm generally more toward using unit tests for base modules then for top ones.

One of basic rules is to have somebody else to write unit test for your code - this way you will also test documentation/javadocs and avoid falling into misunderstaning some process twice in same way.

Writing unit tests is painful, slows down development and is very irritiating if your class change a lot. This is another reason to stick to base classes - their functionality tend to be more fixed over time. But testing small modules is only way to make reasonably working system - debugging top level classes while you cannot trust your base is bad for sanity... For system large enough, bugs in low level code is going to cause more headache then testing it through unit tests.

P.S. In my company, writing unit tests is also used for newcomers so they will know system better - at the same time, they are more likely to find some incosistency/bugs which everybody else is used to avoid subconciously (sp?). And most older programmers really, really hate this job Wink

Artur Biesiadowski
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #5 - Posted 2003-10-30 15:11:09 »

Quote
I have also wanted to use JUnit for my projects... but I find it VERY difficult.

writing tests for trivial methods is easy.  All examples i have seen are trivial.  How do you test REAL CODE?  I asked this on the JUnit mailing list.."how to get started"  they said just dive in a go for it....  I have trouble with that.  It turns out that anything I want ot do needs tests that are at least as complex or more complex than the code they are testing and thus my chance for bugs in the tests is huge..


I hit the same problem, especially when theres just one person working on a project it seems like a huge overhead.

There wouldn't happen to be a java equivilent to Rational Robot would there? Or is this perhaps built in to JUnit and i havn't seen it?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline dsellars

Junior Member




Need to write more games


« Reply #6 - Posted 2003-10-30 16:59:04 »

Looks like we're all struggling with the same problem here.  We think that we should be using unit test but don't know how to get them to work for us.

I agree with swpalmer a relaworld example would be very useful.

Dan.
Offline swpalmer

JGO Coder


Exp: 12 years


Where's the Kaboom?


« Reply #7 - Posted 2003-10-30 17:40:20 »

Quote
This works good for reusable middleware classes, I have not used it for classes at end of food chain - I'm generally more toward using unit tests for base modules then for top ones.


I agree with this.  I mean, I can see how I could write unit tests for an API or something very discrete like that.  But the application itself is more of the glue that times all those discrete things together... it is more blob-like, tying together unrelated bits in complex ways.

Quote
Writing unit tests is painful, slows down development and is very irritiating if your class change a lot. This is another reason to stick to base classes - their functionality tend to be more fixed over time.


No argument with the "painful & slow" point... but your point about testing bases classes because they don't change often seems counter to the point of unit testing in the first place.  If I don't change the base class often, I can spend the time to be really careful when I do,  plus I have all those derived classes in my app - perhaps one of which is likely to break in a noticeable way if the base class has a bug.
Isn't it the code that changes that needs to be constantly tested?

Offline tortoise

Junior Member




<3 Shmups


« Reply #8 - Posted 2003-11-03 02:45:39 »

I think it's difficult to unit test in such a way that it's beneficial. Unit testing done wrong can just lead to many headaches and worst, false positives.

I worked on a project recently where the unit tests violated the public interface to do their job. This caused so many problems it was ridiculous, totally negating any value the tests had. Any change to private implementation meant also changing the tests to correspond. Since the tests used private implementation we really should have "tested the tests", but of course didn't. So there were a lot of situations where the unit tests would all report things were ok but there'd be glaringly obvious bugs in the program, it was just a big mess (and not my idea Smiley )

One thing that unit testing is great for is when new people jump onto a project. Changes they make that cause tests to fail can allow them to learn the code a lot faster.
Offline ENC

Junior Member





« Reply #9 - Posted 2006-10-17 07:16:28 »

Before I reply I must state the warning they gave me...

Warning: this topic has not been posted in for at least 120 days.
Unless you're sure you want to reply, please consider starting a new topic.

haha....

My question is totally different from the topic above..
my question is if JUnit alone is so difficult to use then why other developers care to integrate JUnit into other applications? Isn't that stupid?

Just a question.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cylab

JGO Ninja


Medals: 50



« Reply #10 - Posted 2006-10-17 10:45:00 »

JUnit and creating test suites with it is very simple. The problem is to create and maintain _meaningful_ tests.

Here at work, we really benefit from having unit tests, since it's the only way to say, if our system works the same way as intended after changing something. You will be surrised what kind of sideeffects can occur in a software that is little more than trivial. Smiley

On the other hand we don't use JUnit to test whole applications. We use it to test the base logic and data models of our applications. To test the applications itself we use plain old test protocols and test the functionality by hand.

Mathias - I Know What [you] Did Last Summer!
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #11 - Posted 2006-10-17 12:05:13 »

Since my earlier reply I've actually had a chance to do proper test driven development (TDD) with unit tests and it went very well (not with JUnit though, a custom C++ unit testing framework).

I think it's not particularly difficult, but it does require quite a mental leap from what everyone probably does without thinking now - just trying to carry on before and bolt some unit tests on later is definately not the way to go and is always going to be painful and unproductive. Instead you've really got to shift to doing proper TDD ("Test-driven development by example" by uber programmer Kent Beck is a very good place to start).

IMHO theres two main shifts you've got to make - writing tests first, and *really* concentrating on dependancies.

Writing tests first means that you're focusing on what the external interface should look like. You're not thinking about the internals (much), but how people will actually use your software. This means you get tigher, smaller interfaces which are more useful.

Thinking about dependancies means paying attention to what dependancies you need for each test, and whether the dependancies between classes and modules is sensible. If your tests are big and hairy and complicated that probably means your classes are too dependant on each other. With well-factored code most tests can be ~15 lines long. The book "Working effectively with legacy code" is basically about retro-fitting unit tests onto an existing code base, and most of the book is dedicated to dependancy breaking techniques (which are somewhat different from regular dependancy management work).

For the first couple of weeks I found I was somewhat less productive, but after that mindset shift then it was much quicker. You know instantly when you make a change that breaks existing code. Other people are less likely to break your code (and when they do you can beat them around the head with your unit tests). My defect rate dropped dramatically and stayed low, even as the code base started to get bigger and bigger. You're also much more confident with refactoring and more likely to make those big changes you know you really should. The tests also make great documentation - "how do I foobar a gimlet?" "look at foobarAGimletTest()".

I'm now thinking of adding more tests to my own java games. IMHO the higher level code can stay without tests (because it's higher level, and because theres only me working on it) but lower level stuff should definately be worth it.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline dsellars

Junior Member




Need to write more games


« Reply #12 - Posted 2006-10-17 13:56:46 »

hmmm an old thread (is it me or have threads circa 2003 being popping up alot today?) but interesting....

I've not had chance to use full on TDD yet it's one of those things that I want to exprience in practice.  At work JUnit tests are required but treated very secondry.  It's not so much TDD more units tests are good do unit tests.

OT your post was interesting as I think it is that big mind set jump that I need.  I have tried doing a bit at home with my simple projects.  But I found that I spent all my time writing tests and not actually getting much code written.

The thing is I can't think of a good reason not to do TDD, just a bad one, the perceived "but that takes me twice as long and I don't have much time as it is".  How do you get over this feeling?

Any more thoughts you have on the subjects would be cool.

Cheers,
Dan.
Offline dsellars

Junior Member




Need to write more games


« Reply #13 - Posted 2006-10-17 14:02:05 »

hehe I've just read the whole thread (since writig the post above) and found out I was active in it before!!! bizzare. 

And my experience with units test hasn't really changed even though I now work in a more open environment (new job)!

Does anyonce else that was involved with this thread have any 3 years on comments.

(and have I really being hanging around here that long?)

Dan.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #14 - Posted 2006-10-17 18:51:47 »

Without putting too fine a point on it, I think OT hit the nail on the head - the ease of writing unit tests is proportional to the quality of your code (measured by OOP standards) - and this is why you see huge variance in people's experiences *and* why long term experts say "just dive in" (because for them, and all code they write, and code they expect you to write / have written, it really is that easy).

And IMHO that is why they're fundamentlly so valuable *** - they coerce your code into being better.

***: there are several other areas where they happen to be invaluable for (so far it seems to me) unrelated reasons. For instance, automated and stress testing of massive complex systems, pre- and post-refactoring testing, and others. But I've not really thought about that any more than "huh, they work fantastically well here and I can't see an obvious reason why other than that they are good tests and that I have approximately as many tests as I have public methods" (which, for instance, is why they're invaluable in AT and ST: they exercise almost the entire code base very quickly).

malloc will be first against the wall when the revolution comes...
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #15 - Posted 2006-10-17 20:22:28 »

OT your post was interesting as I think it is that big mind set jump that I need.  I have tried doing a bit at home with my simple projects.  But I found that I spent all my time writing tests and not actually getting much code written.

The thing is I can't think of a good reason not to do TDD, just a bad one, the perceived "but that takes me twice as long and I don't have much time as it is".  How do you get over this feeling?

Largely it was a combination of external situations, without going into the specifics I and a few others were thrust into a different project to get some results fast. There were a whole bunch of big unknowns (new codebase, new hardware, new techniques) and I felt I really needed a safety net. Since unit tests were being used (in principle at least) I jumped on the oppertunity to do things a different way.

It was much slower for the first couple of weeks, and had I been doing it for just hobby stuff I'd probably have given up. But after that initial hump it's a much nicer way of doing things.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline ENC

Junior Member





« Reply #16 - Posted 2006-10-18 01:43:49 »

Haha.. everyone is talking big talk.... do not understand... i am such a noobie...

>.<
Offline noblemaster

JGO Ninja


Medals: 20
Projects: 10


Age of Conquest makes your day!


« Reply #17 - Posted 2006-10-18 04:34:25 »

Quote
Haha.. everyone is talking big talk.... do not understand... i am such a noobie...

* yeah, we got someone else intimidated by buzz-words  Grin *

It's actually super-simple ... but as with many tools out there, it sounds complicated as hell. Basically all you do is test some code. I usually do JUnit tests for client-server functionality. Helps to find bugs before adding it to my my games. You do not actually need JUnit for testing, you could just write some code into the main(...) method to test functionality. E.g.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
public void main(String[] args) {
   // start server
  ...
   // start client
  ...
   // send request from client to server and back and read reponse
  ...
   // check response
  if (response is correct) {
      ...
   }
   else {
      ... output error
   }
}


Using JUnit, you move the code in main(...) to a test method:

1  
2  
3  
4  
5  
6  
import junit.framework.TestCase;
public class TestPay extends TestCase {
  public void testAll() throws Exception {
    ... here's the code from the main method above
  }
}


in testAll() you can use some methods such as "assert" and "fail" to simplify testing. JUnit tests integrate nicely into your build process.

I usually write the tests first (i.e. code in "testAll") and then implement the actual classes that I am planning to implement. It gives you an idea what you are actually planning to do before you write the code you want to write!

Hope that helps  Smiley

Offline ENC

Junior Member





« Reply #18 - Posted 2006-10-20 01:58:46 »

Cool! THanks for the info... but do introduce some new terms... as I am trying to learn as much as possible... ^^

CHeers!
Offline tortoise

Junior Member




<3 Shmups


« Reply #19 - Posted 2006-10-22 16:59:29 »

You do not actually need JUnit for testing, you could just write some code into the main(...) method to test functionality.

Yes but use of JUnit is highly recommended. It's the integration into build systems and IDEs and overall standardization that JUnit gives you that makes it so useful.

I've used unit testing (NUnit in a .NET environment) to great success at my job. The amount of debugging required for the project was reduced significantly. The flexibility of the code was greatly increased as the impact of changes was easily captured in the unit test results. And other developers used the test code itself as an introduction to how the real code worked. There's no doubt that TDD is good stuff.
Offline noblemaster

JGO Ninja


Medals: 20
Projects: 10


Age of Conquest makes your day!


« Reply #20 - Posted 2006-10-22 20:50:17 »

Quote
Yes but use of JUnit is highly recommended. It's the integration into build systems and IDEs and overall standardization that JUnit gives you that makes it so useful.

yes, I fully agree, I use it myself! I was just making an example to describe the concept ...

Offline Martin Strand

Junior Member





« Reply #21 - Posted 2006-10-23 18:53:55 »

There's also TestNG (testng.org) . It's not much different from JUnit but it has a few more nifty features, like the @DataProvider annotation which declares a source for parameters to your test methods:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
@Test(dataProvider="objects")
public void testEquals(Object a, Object b)
{
return a.equals(b);
}

@DataProvider(name="objects")
public Object[][] getObjects()
{
Object a = new String("");
Object b = new String("");
return new Object[][] {{a,b}};
}


TestNG also comes with an eclipse plugin.
Offline ENC

Junior Member





« Reply #22 - Posted 2006-10-24 00:59:51 »

JUst asking... when we are packaging up all our class files, is it recommended to place our Junit files in it as well? Cause I am not sure if the next person who takes over will generate his/her own files.

Cheers!
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Pippogeek (38 views)
2014-09-24 16:13:29

Pippogeek (29 views)
2014-09-24 16:12:22

Pippogeek (18 views)
2014-09-24 16:12:06

Grunnt (42 views)
2014-09-23 14:38:19

radar3301 (24 views)
2014-09-21 23:33:17

BurntPizza (61 views)
2014-09-21 02:42:18

BurntPizza (31 views)
2014-09-21 01:30:30

moogie (36 views)
2014-09-21 00:26:15

UprightPath (49 views)
2014-09-20 20:14:06

BurntPizza (53 views)
2014-09-19 03:14:18
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!