Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualfrob

Posted 04 October 2012 - 04:18 PM

I am a big proponent of TDD, and I've used it extensively since about 2003, on and off when it is appropriate.

1.) Is TDD applicable to game development? I'm guessing the answer is yes for large projects/teams, but I don't know about small project games like what I've mentioned I've done/am working on.

Writing software is a cost. Money is a cost. Your time is a cost. Your sanity and emotional well being are costs. You must learn to weigh and balance costs in your life.

TDD incurs a large cost up front, it is almost a 1:1 cost equal to the cost of development. There have been several studies on the costs of TDD, and they all tend to converge on a 50/50 split. That TDD cost pays for the ability to maintain your code into the indefinite future without worry. The payoff is the "long tail". The longer tail you have, the more benefit you will see.

TDD for stuff that will stick around forever is a good thing. We use TDD and non-TDD unit tests for various libraries such as memory managers, tools, and more. These things will stick around for a long time, and the investment in TDD will pay off over the many years the software will be in use. In this situation it is more cost effective to have instant zero-cost tests that were expensive to create.

TDD for stuff that is transient is a bad thing. We do not use TDD for game code. It is a poor investment for most game code; it is far less expensive to have an army of QA testers and a six-month alpha/beta cycle than to effectively double the development time from 18 months to 36 months.

For personal projects, especially where you don't have the ability to hire an army of QA testers, TDD is a great thing.

2.) If it is, what kinds of tests would one run?


One of the better TDD tutorials is the creation of a Tetris clone. It is available here and is written in Java. It can be easily ported to the language of your choice if you want. That tutorial provides about 30 different TDD steps, then asks you questions to come up with the next 15 or so steps, then lets you finish off on your own. I've worked through it before and found it to provide good advice along the way. A few of the TDD Yahoo Group contributed to the example, (including several well-known names in the TDD world), and simultaneously making your first text-base Tetris clone as learning TDD is a fun way to go.

#3frob

Posted 04 October 2012 - 04:17 PM

I am a big proponent of TDD.

I love TDD. Consequently I am able to judge for myself when it is appropriate to use TDD, and when it is inappropriate for TDD.

1.) Is TDD applicable to game development? I'm guessing the answer is yes for large projects/teams, but I don't know about small project games like what I've mentioned I've done/am working on.

Writing software is a cost. Money is a cost. Your time is a cost. Your sanity and emotional well being are costs. You must learn to weigh and balance costs in your life.

TDD incurs a large cost up front, it is almost a 1:1 cost equal to the cost of development. There have been several studies on the costs of TDD, and they all tend to converge on a 50/50 split. That TDD cost pays for the ability to maintain your code into the indefinite future without worry. The payoff is the "long tail". The longer tail you have, the more benefit you will see.

TDD for stuff that will stick around forever is a good thing. We use TDD and non-TDD unit tests for various libraries such as memory managers, tools, and more. These things will stick around for a long time, and the investment in TDD will pay off over the many years the software will be in use. In this situation it is more cost effective to have instant zero-cost tests that were expensive to create.

TDD for stuff that is transient is a bad thing. We do not use TDD for game code. It is a poor investment for most game code; it is far less expensive to have an army of QA testers and a six-month alpha/beta cycle than to effectively double the development time from 18 months to 36 months.

For personal projects, especially where you don't have the ability to hire an army of QA testers, TDD is a great thing.

2.) If it is, what kinds of tests would one run?


One of the better TDD tutorials is the creation of a Tetris clone. It is available here and is written in Java. It can be easily ported to the language of your choice if you want. That tutorial provides about 30 different TDD steps, then asks you questions to come up with the next 15 or so steps, then lets you finish off on your own. I've worked through it before and found it to provide good advice along the way. A few of the TDD Yahoo Group contributed to the example, (including several well-known names in the TDD world), and simultaneously making your first text-base Tetris clone as learning TDD is a fun way to go.

#2frob

Posted 04 October 2012 - 04:14 PM

I am a big proponent of TDD.

I love TDD. Consequently I am able to judge for myself when it is appropriate to use TDD, and when it is inappropriate for TDD.

1.) Is TDD applicable to game development? I'm guessing the answer is yes for large projects/teams, but I don't know about small project games like what I've mentioned I've done/am working on.

Writing software is a cost. Money is a cost. Your time is a cost. Your sanity and emotional well being are costs. You must learn to weigh and balance costs in your life.

TDD incurs a large cost up front, it is almost a 1:1 cost equal to the cost of development. There have been several studies on the costs of TDD, and they all tend to converge on a 50/50 split. That TDD cost pays for the ability to maintain your code into the indefinite future without worry. The payoff is the "long tail". The longer tail you have, the more benefit you will see.

TDD for stuff that will stick around forever is a good thing. We use TDD and non-TDD unit tests for various libraries such as memory managers, tools, and more. These things will stick around for a long time, and the investment in TDD will pay off over the many years the software will be in use. In this situation it is more cost effective to have instant zero-cost tests that were expensive to create.

TDD for stuff that is transient is a bad thing. We do not use TDD for game code. It is a poor investment for most game code; it is far less expensive to have an army of QA testers and a six-month alpha/beta cycle than to effectively double the development time from 18 months to 36 months.

For personal projects, especially where you don't have the ability to hire an army of QA testers, TDD is a great thing.

2.) If it is, what kinds of tests would one run?


One of the better TDD tutorials is the creation of a Tetris clone. It is available here and is written in Java. It can be easily ported to the language of your choice if you want. That tutorial provides about 30 different TDD steps, then asks you questions to come up with the next 15 or so steps, then lets you finish off on your own. I've worked through it before and found it fairly representative.

#1frob

Posted 04 October 2012 - 04:11 PM

TDD has certain assumptions that don't apply to games development.

I am a big proponent of TDD. I love TDD.

1.) Is TDD applicable to game development? I'm guessing the answer is yes for large projects/teams, but I don't know about small project games like what I've mentioned I've done/am working on.


TDD incurs a large cost up front, it is almost a 1:1 cost equal to the cost of development. That pays for the ability to maintain your code into the indefinite future without worry.

TDD for stuff that will stick around forever is a good thing. We use TDD and non-TDD unit tests for various libraries such as memory managers, tools, and more. These things will stick around for a long time, and the investment in TDD will pay off over the many years the software will be in use. In this situation it is more cost effective to have instant zero-cost tests that were expensive to create.

TDD for stuff that is transient is a bad thing. We do not use TDD for game code. It is a poor investment for most game code; it is far less expensive to have an army of QA testers and a six-month alpha/beta cycle than to effectively double the development time from 18 months to 36 months.

For personal projects, especially where you don't have the ability to hire an army of QA testers, TDD is a great thing.

2.) If it is, what kinds of tests would one run?


One of the better TDD tutorials is the creation of a Tetris clone. It is available here and is written in Java. It can be easily ported to the language of your choice if you want. That tutorial provides about 30 different TDD steps, then asks you questions to come up with the next 15 or so steps, then lets you finish off on your own. I've worked through it before and found it fairly representative.

PARTNERS