Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (475)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 [3]
  ignore  |  Print  
  The Unit Testing Advocacy & Derision Thread  (Read 9227 times)
0 Members and 1 Guest are viewing this topic.
Offline sproingie

JGO Kernel


Medals: 201



« Reply #60 - Posted 2012-07-06 04:04:09 »

I think that a lot of the current push for TDD comes from the dynamic languages / Web development camp where tests largely compensate for the fact that these languages don't have types, i.e.: as Cas said, it's a crutch for shit languages.

The story of the origin may be true (the XP folks came from smalltalk which is more or less dynamic) but it doesn't mean that it's useless in a language with static types.  A type system can prove the absence of certain wrong behaviors, but it can't prove the presence of a correct one.  Of course in the absolute definition of "prove", tests won't do that either, but they do at least provide some assurances against regressions when you refactor code. 

Regression tests have always been a major part of QA, and it's just a consequence of the fact that dev machines have gotten so much more powerful that we can now write them preemptively, and run them with the push of a button.
Offline Roquen
« Reply #61 - Posted 2012-07-06 22:25:06 »

White box & regression testing are awesome when need.  I think that the original point however is that they've become fadish and are being used in places where they're worthless.  "It's the write way to do it"  (yes, I'm aware of my spelling there).  Pointless white box testing is a waste of both computer (and worse) human time.  As an example I've seen exhaustive test units for Remez method routines...WTF???  Think damn-you!  Don't just do because they say you should.
Offline sproingie

JGO Kernel


Medals: 201



« Reply #62 - Posted 2012-07-06 22:55:09 »

I think the takeaway is that tests should arise simultaneously with source and not as an afterthought after things break, and I'm convinced that's still a good idea.

I'm not a fan of "test first" where implementation is an exercise in turning red bars green, no.  To me, that's a sort of dogma that actually hurts testing, since people may write sloppy tests just to bring coverage up, then write crappy code that just manages to turn the bars green.  But really, no methodology can save a codebase written without any respect for craft.

BTW, what's a "Remez method routine"?
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #63 - Posted 2012-07-06 23:01:44 »

A polynomial or rational (min-max approximation) of a function generated using Remez exchange method.  (i.e. You know in advance exactly the set the values where the maximum error occurs and what the error is...so white-box testing is trivial)

BTW: When I said white-box testing a couple of post back...I meant black-box testing.  Bad me.
Offline Gudradain
« Reply #64 - Posted 2012-08-05 18:01:41 »

Sorry for reviving this thread but I have to share.

For one month I have been working on a project with 3 other developers that got absolutely no clue what they are doing. When they try to fix something they always break 2 other things. The code is nearly unmanageable. The only thing that still save me are the unit test that I wrote. Every time they change something I can run my test and see if they broke something again. If one test fail, I refuse to merge their work into the main branch.

Really I think unit test were meant for case like that...
Offline sproingie

JGO Kernel


Medals: 201



« Reply #65 - Posted 2012-08-05 18:54:16 »

Indeed, testing becomes a Big F**ing Deal when you have multiple developers, since documentation isn't always Ye Olde Tome Of The Holy Spec Volumes I-XVII -- and even when it is, who wants to dedicate days or weeks to reading the spec when the API is supposed to define boundaries of acceptable inputs anyway?
Offline Roquen
« Reply #66 - Posted 2012-08-05 19:21:37 »

Really I'd say that this is like just giving aspirin to someone seriously ill..treating the symptom and not the problem.  The idea of test units should be to reduce engineering cost and not increase them, which sounds like what's happening in this case.
Offline Gudradain
« Reply #67 - Posted 2012-08-05 19:28:38 »

Have you tried to manual test every little change that other, not so good, developers are committing to make sure they don't crash the whole project?

Trust me it reduces engineering cost in my case...  Emo
Offline ags1

JGO Ninja


Medals: 46
Projects: 2
Exp: 5 years


Make code not war!


« Reply #68 - Posted 2012-08-05 19:38:34 »

A software system developed by even a small team of say ten developers is much too complex for every developer to have a full understanding of the system, or to fully foresee the effects of any given change. For this, unit tests are essential. If I was in a job interview and I was told 'we don't do unit testing here', I don't think I would take the job. At least, the money would have to be very good :-)

Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #69 - Posted 2012-08-05 21:32:48 »

Hey, if you find a team that's making money and they don't do unit testing, it's probably because they work well enough together not to need to waste their time on it.

Oh for design by contract. Sigh.

Cas Smiley

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Roquen
« Reply #70 - Posted 2012-08-06 13:15:36 »

You're missing my point.  Writing and running these test do not advance the project.  Multiply the time your spending by two and that's your opportunity cost of not progressing your project.  The fact that you might be wasting less time than otherwise doesn't change the fact your wasting time.

+1 for contracts.
Offline Riven
« League of Dukes »

JGO Overlord


Medals: 742
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #71 - Posted 2012-08-06 15:23:29 »

Taking things out of context (or to their extremes) has rarely been associated with a good conversation, right?

Should we put too much effort into test code? No.
Should we put too little effort into test code? No.
Should we put just enough effort into test code? Yes.
How much effort is just enough? It depends.

Thanks for your valuable time! Kiss

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline ctomni231

JGO Wizard


Medals: 98
Projects: 1
Exp: 7 years


Not a glitch. Just have a lil' pixelexia...


« Reply #72 - Posted 2012-08-07 01:29:55 »

I thought unit tests was more of a "prevent errors" than "fix errors".
In terms of large projects, I thought unit tests are more for "conforming your modules to design specs" rather than "fixing broken code".

Using Unit Tests to fix code sounds, kinda silly. We have debuggers for that and they work rather well. I thought the reason companies spent so much time on unit tests so that modules written can work everywhere.

Does it waste a lot of valuable time? Hell yeah!
Is it beneficial to large coding groups? Depends.

It is exactly like what the first post stated about JUnit tests, it is just a way to plaster over the cracks of coders merging modules together. Why it takes up soo much development time really just depends on the coders themselves. "Writing tests is just a drag, and so is fixing your code to match those tests. Green checking is just boring... hack-and-slash code to get the green check. Yay!" Just because you hack code together, doesn't make it robust or readable. But, alas, that is what JUnit tests promote when it comes to large coding groups.

We just want to code, not test. What is this, a driving school simulation?  Roll Eyes


Offline pitbuller
« Reply #73 - Posted 2012-08-07 01:59:08 »

I have never liked unit testing becouse it's divide stuff in two places and that cause just too much headache. Nowadays I just use asserts to keep class invariants in shape and call it a day.
Offline sproingie

JGO Kernel


Medals: 201



« Reply #74 - Posted 2012-08-07 04:11:14 »

Invariants are great to have, but it still takes a test to verify that a corner case isn't going to violate them.  Otherwise, this is your story:


Offline princec

JGO Kernel


Medals: 339
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #75 - Posted 2012-08-07 10:16:49 »

Yeah but that'd be a system test wouldn't it Smiley And those are good.

Cas Smiley

Pages: 1 2 [3]
  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.

ctomni231 (32 views)
2014-07-18 06:55:21

Zero Volt (28 views)
2014-07-17 23:47:54

danieldean (24 views)
2014-07-17 23:41:23

MustardPeter (25 views)
2014-07-16 23:30:00

Cero (40 views)
2014-07-16 00:42:17

Riven (42 views)
2014-07-14 18:02:53

OpenGLShaders (29 views)
2014-07-14 16:23:47

Riven (29 views)
2014-07-14 11:51:35

quew8 (27 views)
2014-07-13 13:57:52

SHC (63 views)
2014-07-12 17:50:04
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!