Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (780)
Games in Android Showcase (233)
games submitted by our members
Games in WIP (857)
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  
  Anyone use jUnit?  (Read 3874 times)
0 Members and 1 Guest are viewing this topic.
Offline 20thCenturyBoy

Senior Devvie

Medals: 3

So much to learn, so little time.

« Posted 2004-05-13 23:36:30 »

I'm just reading up about jUnit and it looks pretty useful, do any of you guys use it? Presumably it would be just as useful for J2SE game devs as for J2EE devs. If you do use it do you find it speeds up development time?


"I have never done unit testing and I don’t find it a very useful concept" - Jonathan Blow
Offline D.t.O

Junior Devvie

Psych'd about Java Games

« Reply #1 - Posted 2004-05-14 00:45:25 »

jUnit is pretty good at doing what it is supposed to do.

In the beginning, it slows dev time, but in the end, IMO, you save time because you can re-run the same test cases (as opposed to ad-hoc testing).

Wow. That really sounded like some lame cliche. Sorry.

     - D.t.O
Offline kevglass

« JGO Spiffy Duke »

Medals: 319
Projects: 25
Exp: 22 years

Coder, Trainee Pixel Artist, Game Reviewer

« Reply #2 - Posted 2004-05-14 04:20:30 »

Since I rarely get games past the concept stage JUnit hasn't given me any benefit so I've stopped attempting to use it since it uses up my inital dev time.

However, the concept seems pretty sound.


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

Junior Devvie

where I should sign ?

« Reply #3 - Posted 2004-05-14 05:56:44 »

I use it for validate some aglorithm, I find it pretty usefull. I try to write the test code first (not all the time Smiley) )  for validate the conception, in place of writing an UML scenario diagram
Offline Herkules

Senior Devvie

Friendly fire isn't friendly!

« Reply #4 - Posted 2004-05-14 06:29:58 »

helps maintaining base libs. I use it.

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

Senior Newbie

« Reply #5 - Posted 2004-05-14 13:32:07 »

Using automated tests takes some getting used to, but once you start you'll never go back. And JUnit is the authority in this area, so yah it's good.

Test suites do take some maintenance: normally if you change the behaviour of a method/class, you only have to update the client code, now you also have to update the tests. But this is trivial compared to the benefits.

With a comprehensive test suite, you're free to make major implementation modifications without fear, and without the need to perform extensive manual testing afterwards (as long as your tests accurately represent how you're using the code in the project itself). This is even more benificial in team development, were developer B can modify developer A's code without fear of breaking the behaviour.

I also use unit tests to help in design: by writing the test case up front, I get a better idea of how the class will probably be used, and what clients may end up doing to try and break it.

There's nothing like the warm fuzzy of changing a thousand lines of code and then having 0 errors in your suite of 500 tests.
Offline swpalmer

JGO Coder

Exp: 12 years

Where's the Kaboom?

« Reply #6 - Posted 2004-05-14 16:19:49 »

I have wanted to use JUnit for over a year now.. however I must say I can't figure out how to get started...   Right off the bat the workload is doubled in terms of designing and maintaining good reasonable tests.  In fact in many cases it seems that the tests are more work than coding the test the application.

I would love to have the unit tests available.. but I don't know how to make them less "expensive".   My time debugging is MUCH less than the time it would take to design and build (bug-free) tests.

If anyone has the secret please let me know.  So far all I've been told is that you just have to dive in and start doing unit tests.. well that's fine, but I haven't got the luxury of tripling my development time.

Offline blahblahblahh

JGO Coder

Medals: 1

« Reply #7 - Posted 2004-05-14 16:53:39 »

SWP: IME, you need a good harness for running the tests. Unfortunately, JUnit is almost non-existent - it does practically nothing - and I've been watching it for ages hoping it would (eventually) grow and gain a complete set of harnesses...

If you look around the junit site, you can find lots of 3rd party harnesses and if you're lucky may find ones that suite you. But there aren't that many Sad.

For instance, we've coded unit-testing support directly into the core gameserver for the GrexEngine; this means that writing new unit tests is fairly simple: you can assume that the whole gameserver is already up-and-running and that various config and init stuff has already happened. This is more than just an "init-stage" for the unit-tests (can't remember what jargon name junit uses for it Smiley), because the tests themselves are only invoked from inside a pre-configured pre-started game-server. If you invoked the tests from outside the game-server, and had "starting the server" as part of the test, it would add minutes to the exec time of every test, and would be very error prone and hard to maintain.

The other part of unit-testing where you can save a lot of time is by learning to be cunning about the tests you run. XP people often say "test everything in the contract, then add a test for every bug you ever find", which is good, but...there's definitely a mindsight that lets you write new unit tests from scratch about 5 times as efficiently as if you do so naively. I'm pretty sure there are articles spread out on the web which offer advice on getting into this mindsight, although I've not yet seen a "thinking in unit-tests" (come on, Bruce!) Wink which would be very helpful to many people I suspect.

I find that the most effective *initial* unit tests are ones written by ignoring the spec and all the implementation. Instead, start from the use-cases (if you don't know what use-cases are, do a google; they're a simple concept used widely, e.g. in UML design). Just write unit-tests that mirror the use-cases; this generally is a lot less than testing the contract of the method/API and yet exercises 99% of the downtime/damage that bugs will cause to user-code: people code to contracts less closely than they code to use-cases Smiley.

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

Senior Devvie

Friendly fire isn't friendly!

« Reply #8 - Posted 2004-05-15 08:32:52 »

There IMHO is one big objective against test-driven development, that is if you have hundreds of tests and then need to change code interfaces or use-cases significantly (or sometimes only a little) .... you have to re-evaluate all tests against the new specs. And this can be a real pain-in-the-ass.
Esp. then there is no good mean against bugs/misunderstandings in the tests themselves and many might get pretty meaningless or even wrong.

So what about tests for the tests (having a recursive problem domain)?

Concerning tests in complex environments: yes, difficult with JUnit. setup() and teardown() are no suitable places to start and shutdown servers. One way around that is to work with mock server objects to test clients.  Sometimes it is possible to create them.

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Pages: [1]
  ignore  |  Print  

hadezbladez (761 views)
2018-11-16 13:46:03

hadezbladez (394 views)
2018-11-16 13:41:33

hadezbladez (758 views)
2018-11-16 13:35:35

hadezbladez (200 views)
2018-11-16 13:32:03

EgonOlsen (2401 views)
2018-06-10 19:43:48

EgonOlsen (2581 views)
2018-06-10 19:43:44

EgonOlsen (1486 views)
2018-06-10 19:43:20

DesertCoockie (2149 views)
2018-05-13 18:23:11

nelsongames (1967 views)
2018-04-24 18:15:36

nelsongames (2648 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 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‑
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!