Re: Unity3d and TDD

"Carlo Bottiglieri [email protected] [testdrivendevelopment]" <[email protected]> Fri, 25 Mar 2016 17:34:17 +0000
Newsgroups gmane.comp.programming.test-driven-development
Message-ID <CAKaqiKJ4xOtQqS6qZJFNaNXOWjTiYF6KndqCrYJHo-xQjkhwUg@mail.gmail.com>
Hello Avi,
your email spurred me to write something I wanted to write since a very
long time : how I do tdd in Unity. Luckily I was on holiday the days, so I
could put some real time into it; I hope you'll find it useful :
https://minnenratta.wordpress.com/2016/03/25/test-driving-a-unity-game/

Cheers,

Carlo

On Tue, Mar 22, 2016 at 4:19 PM Avi Kessner [email protected]
[testdrivendevelopment] <[email protected]> wrote:

>
>
> The unique thing about Unity is all the hard references you make in the
> scene with the dragging and dropping of components. It makes everything so
> tightly coupled it scares me. I was hoping there was some good, proven,
> design patterns out there to help decouple those things.
> Hopefully, as we move forward past everything that has a strong UI element
> it will be easier to get back into proper coding habits.
> And don't get me stared on the illegible file format that scenes get saved
> as, making me feel like I'm hacking the matrix whenever there is a git
> conflict.
>
> On Mar 22, 2016 2:31 PM, "Colin Vipurs [email protected]
> [testdrivendevelopment]" <[email protected]> wrote:
>
>>
>>
>> I've only done a small amount of Unity and didn't do any TDD there (I
>> know, my bad), but I would take the same approach I would if it was a Swing
>> or Android app - move as much code as possible to be agnostic of the
>> infrastructure it is running in and test that in isolation.
>>
>> I would have a series of ports, a la ports/adapters, that allow the
>> domain logic to communicate to/from the Unity layer and have the domain
>> logic only be aware of those, then provide adapters into Unity.  The
>> biggest downside I see from this is that it will undoubtedly bloat your
>> code and could _potentially_ have a performance impact depending on the
>> type of game you're making.
>>
>> On Tue, Mar 22, 2016 at 10:47 AM, 'Donaldson, John'
>> [email protected] [testdrivendevelopment] <
>> [email protected]> wrote:
>>
>>>
>>>
>>> Yes, I was just testing stuff I was delegating to. Not grasping the
>>> thorny MonoBehaviour.
>>>
>>> I did see somewhere that Model-View-Controller and Dependency Injection
>>> could let you TDD into MonoBehaviour sub-classes.
>>>
>>> Quite a good discussion here:
>>> http://forum.unity3d.com/threads/test-driven-development.35901/
>>>
>>> J.
>>>
>>> From: [email protected] [mailto:
>>> [email protected]]
>>> Sent: 22 March 2016 10:46
>>> To: [email protected]
>>> Subject: Re: [TDD] Unity3d and TDD
>>>
>>>
>>>
>>>
>>>
>>> I have no idea about how Unity works, but perhaps instead of writing
>>> your behaviour in a class that extends monobehavior, you could create a
>>> pure-C# object and delegate all interesting stuff to it.
>>>
>>> On Tue, Mar 22, 2016 at 10:30 AM, Avi Kessner [email protected]<mailto:
>>> [email protected]> [testdrivendevelopment] <
>>> [email protected]<mailto:
>>> [email protected]>> wrote:
>>>
>>>
>>> How do you make classes that extend monobehavior testable? Or maybe I'm
>>> just not far enough into the project where I can use composition on those
>>> bits.
>>> On Mar 22, 2016 11:04 AM, "'Donaldson, John' [email protected]
>>> <mailto:[email protected]> [testdrivendevelopment]" <
>>> [email protected]<mailto:
>>> [email protected]>> wrote:
>>>
>>>
>>> Avi - nice to see you're still out there :-) I've played around a bit
>>> with Unity and took the weak position vis-à-vis TDD.
>>> That is: the visual interface is tested by looking at it and the rest is
>>> just normal C# code with normal tests.
>>>
>>> John D.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> [Non-text portions of this message have been removed]
>>>
>>>
>>
>>
>> --
>> Maybe she awoke to see the roommate's boyfriend swinging from the
>> chandelier wearing a boar's head.
>>
>> Something which you, I, and everyone else would call "Tuesday", of course.
>>
> 
>