¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Testdrivendevelopment
  2. Messages
Expanded Topics Messages Polls
Date
Re: [TDD] Giving Up on TDD

 

A more credentialed rejection of TDD, coming from Dave Thomas, one of the original writers of the Agile Manifesto (which for reasons he explains here, he would rather call a manifesto on agility). ?The linked time discusses about the value of testing practices .


?
Alan Baljeu


From: "Avi Kessner akessner@... [testdrivendevelopment]"
To: testdrivendevelopment@...
Sent: Thursday, March 31, 2016 8:46 AM
Subject: Re: [TDD] Giving Up on TDD

?
I have to shake my head that the need for TDD still isn't better understood.
I guess the current generation has been living their whole life where "Nothing ever works", that they see no need to ensure that it does, actually indeed work.

I'm glad to see that at least there is agreement that tests are needed at some point, but they still don't seem to get that TDD is the only way to have confirmation as to what areas of your code needs testing.

brought to you by the letters A, V, and I
and the number 47

On Thu, Mar 31, 2016 at 1:52 PM, Josue Barbosa dos Santos josuesantos@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:
?
For Knowledge
Re: [TDD] Giving Up on TDD

 

I have to shake my head that the need for TDD still isn't better understood.
I guess the current generation has been living their whole life where "Nothing ever works", that they see no need to ensure that it does, actually indeed work.

I'm glad to see that at least there is agreement that tests are needed at some point, but they still don't seem to get that TDD is the only way to have confirmation as to what areas of your code needs testing.

brought to you by the letters A, V, and I
and the number 47

On Thu, Mar 31, 2016 at 1:52 PM, Josue Barbosa dos Santos josuesantos@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

?

For Knowledge
Giving Up on TDD

 

For Knowledge
Re: [TDD] Unity3d and TDD

 

That blog post is exactly the sort of thing I was looking for! Thank you so much!? I hope it gets many readers.

brought to you by the letters A, V, and I
and the number 47

On Fri, Mar 25, 2016 at 8:34 PM, Carlo Bottiglieri carlo.bottiglieri@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

?

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 :?

Cheers,

Carlo

On Tue, Mar 22, 2016 at 4:19 PM Avi Kessner akessner@... [testdrivendevelopment] <testdrivendevelopment@...> 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 zodiaczx6@... [testdrivendevelopment]" <testdrivendevelopment@...> 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' john.m.donaldson@... [testdrivendevelopment] <testdrivendevelopment@...> 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:

J.

From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: 22 March 2016 10:46
To: testdrivendevelopment@...
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 akessner@...akessner@...> [testdrivendevelopment] <testdrivendevelopment@...testdrivendevelopment@...>> 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' john.m.donaldson@...john.m.donaldson@...> [testdrivendevelopment]" <testdrivendevelopment@...testdrivendevelopment@...>> 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.
Re: [TDD] Unity3d and TDD

 

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 :?

Cheers,

Carlo

On Tue, Mar 22, 2016 at 4:19 PM Avi Kessner akessner@... [testdrivendevelopment] <testdrivendevelopment@...> 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 zodiaczx6@... [testdrivendevelopment]" <testdrivendevelopment@...> 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' john.m.donaldson@... [testdrivendevelopment] <testdrivendevelopment@...> 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:

J.

From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: 22 March 2016 10:46
To: testdrivendevelopment@...
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 akessner@...akessner@...> [testdrivendevelopment] <testdrivendevelopment@...testdrivendevelopment@...>> 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' john.m.donaldson@...john.m.donaldson@...> [testdrivendevelopment]" <testdrivendevelopment@...testdrivendevelopment@...>> 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.













--
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.
Re: [TDD] Unity3d and TDD

 

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 zodiaczx6@... [testdrivendevelopment]" <testdrivendevelopment@...> 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' john.m.donaldson@... [testdrivendevelopment] <testdrivendevelopment@...> 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:

J.

From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: 22 March 2016 10:46
To: testdrivendevelopment@...
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 akessner@...akessner@...> [testdrivendevelopment] <testdrivendevelopment@...testdrivendevelopment@...>> 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' john.m.donaldson@...john.m.donaldson@...> [testdrivendevelopment]" <testdrivendevelopment@...testdrivendevelopment@...>> 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.
Re: [TDD] Unity3d and TDD

 

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' john.m.donaldson@... [testdrivendevelopment] <testdrivendevelopment@...> 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:

J.

From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: 22 March 2016 10:46
To: testdrivendevelopment@...
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 akessner@...akessner@...> [testdrivendevelopment] <testdrivendevelopment@...testdrivendevelopment@...>> 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' john.m.donaldson@...john.m.donaldson@...> [testdrivendevelopment]" <testdrivendevelopment@...testdrivendevelopment@...>> 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.
Re: [TDD] Unity3d and TDD

 

Thanks for the link. Was hoping for something that was updated with the latest version of Unity, but I'll take what I can get.
I only worry that the lack of updates is an indication that it's not the right workflow.

On Mar 22, 2016 12:47 PM, "'Donaldson, John' john.m.donaldson@... [testdrivendevelopment]" <testdrivendevelopment@...> 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:

J.

From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: 22 March 2016 10:46
To: testdrivendevelopment@...
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 akessner@...akessner@...> [testdrivendevelopment] <testdrivendevelopment@...testdrivendevelopment@...>> 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' john.m.donaldson@...john.m.donaldson@...> [testdrivendevelopment]" <testdrivendevelopment@...testdrivendevelopment@...>> 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]
Re: [TDD] Unity3d and TDD

Donaldson, John
 

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:

J.

From: testdrivendevelopment@... [mailto:testdrivendevelopment@...]
Sent: 22 March 2016 10:46
To: testdrivendevelopment@...
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 akessner@...<mailto:akessner@...> [testdrivendevelopment] <testdrivendevelopment@...<mailto:testdrivendevelopment@...>> 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' john.m.donaldson@...<mailto:john.m.donaldson@...> [testdrivendevelopment]" <testdrivendevelopment@...<mailto:testdrivendevelopment@...>> 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.
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 akessner@... [testdrivendevelopment] <testdrivendevelopment@...> 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' john.m.donaldson@... [testdrivendevelopment]" <testdrivendevelopment@...> 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.





Re: [TDD] Unity3d and TDD

 

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' john.m.donaldson@... [testdrivendevelopment]" <testdrivendevelopment@...> 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.


Re: [TDD] Unity3d and TDD

Donaldson, John
 

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.
Re: [TDD] Unity3d and TDD

 

The general advice with any framework is that you can test drive the behavior you want at a higher level of abstraction than the framework and wrap the framework bits with a thin layer that is under your control. The goal is to test drive "business logic" and not to test the framework.?

On Tuesday, March 22, 2016, Avi Kessner akessner@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

?

The latest forum posts for Unity3d and TDD don't say much other than
its not really possible and the tools available aren't great, they are
also a few years old.

Anyone know if there are design patterns or tools which have been
developed in the past few years?

brought to you by the letters A, V, and I
and the number 47
Unity3d and TDD

 

The latest forum posts for Unity3d and TDD don't say much other than
its not really possible and the tools available aren't great, they are
also a few years old.

Anyone know if there are design patterns or tools which have been
developed in the past few years?



brought to you by the letters A, V, and I
and the number 47
Justify ¨C 100% rule-based

[email protected]
 

We are about a week away from the GA release of a JUnit testing tool entitled "Justify". There is a long story (~12 years) that centers on the pursuit of a testing approach with "real objects" (or more precisely 'functionally equivalent services') at near-mock performance.

If you are hands-on in the TDD space we would especially cherish hearing from you... whether it be comments on the documentation or the tool itself:

?Show less
Re: [TDD] Let's Talk About TDD, Baby!

 

Hi Elliot,

Overall that's a nice post, a good primer for TDD, I just wanted to pick up on a couple of points:

1) At no point do I remember you mentioning seeing the test fail /for the right reason/.? In your first test you move from compilation failure -> test pass.? At no point do you see your test actually fail because the assertion was wrong.? I consider this quite an important step as it both verifies my test is correct and lets me know the diagnostics are useful when the test fails

2) You're using triangulation to reach your solution but for this problem I would suggest some steps could be avoided by applying DRY and removing duplication between the test + production code.? I was running a session lately for some people experienced in TDD and when I talked about this they had an "Aha!" moment that lets them go from the specific to the generic solution quicker

Because this is a toy example it might be worth pointing out how easy it is to actually mess this code up without tests, the usual way is that you write the code as you think about it and how the problem is presented:

if (divisible by 3) Fizz
if (divisible by 5) Buzz
if (divisible by 3 and 5) FizzBuzz

To the naked eye this /looks/ correct but doesn't work as expected.

On Mon, Feb 22, 2016 at 1:40 PM, elliot.chance@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

?

Hi everyone, this is my first post... Just wanted to get some feedback on my blog post as a started to TDD:
Let's Talk About TDD, Baby! - A Brief Overview
Preview by Yahoo





--
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.
Let's Talk About TDD, Baby!

 

Hi everyone, this is my first post... Just wanted to get some feedback on my blog post as a started to TDD:
Invitation

 

I've shared a secured document with you on Google drive.

Google Drive: create, share, and keep all your stuff in one place.

Re: [TDD] More Typing, Less Testing: TDD with Static Types

 

This is definitely a case of "old wine in a new bottle." That said, if the particular bottling of the concepts speaks to an audience in ways that earlier formulations didn't, it has value.

Much of what is written in part 2 reflects the weakness of earlier Java as compared to modern Java. I want to go back over the examples myself, working in C#. So I guess the bottling does even appeal to me!

Charlie

On Wed, Dec 17, 2014 at 4:14 AM, Josue Barbosa dos Santos josuesantos@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

?

Hello All,

I found this blog posts about TDD and typing. The first is a introduction and the second is an example using the same example in the book of Kent Beck (Test Driven Development by Example).?

The author claim that thinking int the types first leads to a better code than the pure use of TDD as did by Kent in the book.

More Typing, Less Testing: TDD with Static Types, Part 1

More Typing, Less Testing: TDD with Static Types, Part 2

Any thoughts?

--?
Abra?os,
´³´Ç²õ³Ü¨¦
Re: [TDD] More Typing, Less Testing: TDD with Static Types

 

¿ªÔÆÌåÓý

Hi Josue,

On Dec 17, 2014, at 7:14 AM, Josue Barbosa dos Santos josuesantos@... [testdrivendevelopment] <testdrivendevelopment@...> wrote:

I found this blog posts about TDD and typing. The first is a introduction and the second is an example using the same example in the book of Kent Beck (Test Driven Development by Example).?

The author claim that thinking int the types first leads to a better code than the pure use of TDD as did by Kent in the book.

More Typing, Less Testing: TDD with Static Types, Part 1

More Typing, Less Testing: TDD with Static Types, Part 2

Any thoughts?

The articles are interesting and deserve due consideration.

The code may be better: it¡¯s largely a matter of taste.?

If I wanted to write an article showing that my approach was better than Kent¡¯s, I¡¯d just work until my code was clearly better, no matter how long it took, then claim that it was my approach that made it work. I¡¯m not saying the author did that: I¡¯m saying that it would be a good way to ¡°show¡± that one method works better.

Certainly one does a different level and style of testing in a language with static types than in one without. Also one types a lot of redundant type-related information. The trade-off is not clear.

Personally, I do not find that doing ¡°less typing¡± makes my code better, nor that it lets me go faster. I seem to be limited by my ability to think. I suppose if I were smarter than I am, my typing might slow me down, but I think for most of us, ¡°less typing¡± shouldn¡¯t be a high priority.

Again, the articles are interesting and deserve due attention and thought. Then, readers should try the various approaches and find out what works best for them.

Regards,

Ron Jeffries
I'm not bad, I'm just drawn that way. ?-- Jessica Rabbit

641 - 660 of 36280