Comments on: Undeniable logic For bite-sized chunks of functionality, unit tests are appropriate. "Given this normal and this position and this light, do I get the right color back?" For larger sections of the code the terminology is "functional tests," these are the tests that are likely scripted in some way to start up the engine, throw a bunch of stuff at it, see what happens, and check for constraint violations (e.g. there were no enemies in this scenario, so the player should not be injured). For bite-sized chunks of functionality, unit tests are appropriate. “Given this normal and this position and this light, do I get the right color back?” For larger sections of the code the terminology is “functional tests,” these are the tests that are likely scripted in some way to start up the engine, throw a bunch of stuff at it, see what happens, and check for constraint violations (e.g. there were no enemies in this scenario, so the player should not be injured).

]]>
By: TomP/2011/04/12/undeniable-logic/#comment-2659 TomP Wed, 13 Apr 2011 00:21:01 +0000 Do you honestly believe that Michelangelo climbed up on the ladder and did the whole Sistine Chapel freehand in one shot? I would have guessed that he roughed it out first and then went in and "painted by numbers" once it was structured the way he wanted. I wonder how large his team was? I suspect that more structure is desirable with larger team sizes. Do you honestly believe that Michelangelo climbed up on the ladder and did the whole Sistine Chapel freehand in one shot? I would have guessed that he roughed it out first and then went in and “painted by numbers” once it was structured the way he wanted.

I wonder how large his team was? I suspect that more structure is desirable with larger team sizes.

]]>
By: Francesco Carucci /2011/04/12/undeniable-logic/#comment-2651 Francesco Carucci  Tue, 12 Apr 2011 20:09:49 +0000 Dan, I will argue the case for Unit Testing and TDD in another post (or series of posts). This post would like to focus more on how to communicate your ideas (right or wrong) in an effective manner: this is where I badly need your input and suggestions cause I've found it to be my weak spot. Dan, I will argue the case for Unit Testing and TDD in another post (or series of posts). This post would like to focus more on how to communicate your ideas (right or wrong) in an effective manner: this is where I badly need your input and suggestions cause I’ve found it to be my weak spot.

]]>
By: Dan Olson/2011/04/12/undeniable-logic/#comment-2647 Dan Olson Tue, 12 Apr 2011 19:09:37 +0000 That's a difficult one, and unit testing is a particularly difficult example, full blown TDD requires a lot more code and a paradigm shift in the way you work, which puts certain developers with certain styles off right away. I can only suggest in any case that you lead by example, show "John" how you like to work, and what the benefits are to you, rather than what they would be to him. Like you say, he wants to be free to try it for himself, rather than feel he's having his working style shoehorned into someone else's. Better still, wait five years. Either everyone will be doing it, or no-one will even remember what it is. :) That’s a difficult one, and unit testing is a particularly difficult example, full blown TDD requires a lot more code and a paradigm shift in the way you work, which puts certain developers with certain styles off right away.

I can only suggest in any case that you lead by example, show “John” how you like to work, and what the benefits are to you, rather than what they would be to him. Like you say, he wants to be free to try it for himself, rather than feel he’s having his working style shoehorned into someone else’s.

Better still, wait five years. Either everyone will be doing it, or no-one will even remember what it is. :)

]]>
By: Rob Ashton/2011/04/12/undeniable-logic/#comment-2640 Rob Ashton Tue, 12 Apr 2011 15:39:36 +0000 While I appreciate the article itself isn't about unit testing, I'd be interested to see how games developers tackle unit tests in scenarios where the assertion itself isn't too determinative. When I'm writing C# or any other managed language, I move towards 'proper' TDD where I let the tests guide both the design and structure of my code, writing an outside 'acceptance' test, and then more fine-grained unit tests as and when I deem them to be required. I'm finding with my Javascript, at least with the core engine stuff that a lot of my tests involve booting up the engine, firing a component at it and just checking nothing falls over. They're *definitely* useful, as proven yesterday when I had to port all my Javascript across to CommonJS format and run it on the server, but it's not TDD and I'd find it hard to write any fine grained tests there. Perhaps it's impossible, perhaps I should write a blog entry about <b>that</b> - I have quite a queue already though, I'd love to have a proper discussion about it. While I appreciate the article itself isn’t about unit testing, I’d be interested to see how games developers tackle unit tests in scenarios where the assertion itself isn’t too determinative.

When I’m writing C# or any other managed language, I move towards ‘proper’ TDD where I let the tests guide both the design and structure of my code, writing an outside ‘acceptance’ test, and then more fine-grained unit tests as and when I deem them to be required.

I’m finding with my Javascript, at least with the core engine stuff that a lot of my tests involve booting up the engine, firing a component at it and just checking nothing falls over. They’re *definitely* useful, as proven yesterday when I had to port all my Javascript across to CommonJS format and run it on the server, but it’s not TDD and I’d find it hard to write any fine grained tests there.

Perhaps it’s impossible, perhaps I should write a blog entry about that – I have quite a queue already though, I’d love to have a proper discussion about it.

]]>
By: Wolfgang Engel/2011/04/12/undeniable-logic/#comment-2636 Wolfgang Engel Tue, 12 Apr 2011 14:12:28 +0000 John, Malcom, Unit Testing is just a pretext here, the point I'm trying to make is that you can convince "John" to try out something if you can tune in the way he wants information to be expressed to him, which is more difficult in my opinion than the technicalities of our job, and something I'm so very open to learn how to do properly and consistently. if you have suggestions to throw at me, please do. John, Malcom, Unit Testing is just a pretext here, the point I’m trying to make is that you can convince “John” to try out something if you can tune in the way he wants information to be expressed to him, which is more difficult in my opinion than the technicalities of our job, and something I’m so very open to learn how to do properly and consistently. if you have suggestions to throw at me, please do.

]]>
By: Javier Arevalo/2011/04/12/undeniable-logic/#comment-2633 Javier Arevalo Tue, 12 Apr 2011 12:01:25 +0000 You write "Unit Testing" here, even capitalising it, but, from the context and your last definition, do you really mean writing tests before code ("test driven development")? You can (and many of us do) happily write unit tests after having written solutions to the problem. They are still unit tests, so this isn't just a minor semantic point. Studies have indeed shown that writing unit tests before code can be effective. Other studies have shown similar productivity, particularly amongst experienced developers, where writing tests after code is effective. Others have shown that behaviour driven development, testing things at a slightly different angle to unit tests, are effective. So your points are valid and your final definition is very nicely nuanced (using "effective" rather than "better" or "best"), but I'm wondering if something was lost in the translation to text here. You write “Unit Testing” here, even capitalising it, but, from the context and your last definition, do you really mean writing tests before code (“test driven development”)? You can (and many of us do) happily write unit tests after having written solutions to the problem. They are still unit tests, so this isn’t just a minor semantic point.

Studies have indeed shown that writing unit tests before code can be effective. Other studies have shown similar productivity, particularly amongst experienced developers, where writing tests after code is effective. Others have shown that behaviour driven development, testing things at a slightly different angle to unit tests, are effective. So your points are valid and your final definition is very nicely nuanced (using “effective” rather than “better” or “best”), but I’m wondering if something was lost in the translation to text here.

]]>
By: John/2011/04/12/undeniable-logic/#comment-2626 John Tue, 12 Apr 2011 10:54:41 +0000