Hi Bob, I absolutely agree that unit test can be a big win if done properly (as you wrote this is not as simple as it looks like. The very specific corner cases are the important test cases).
But I was specifically answering to the original poster. For a 14 years old programmer who is starting to do game programming I consider unit testing one of the less important points. IMHO most important is to keep the fun at programming. Second is to learn to estimate what one person can achieve and what not. Later if he wants to go the professional root he will be bombarded with design patterns, best practices and so on. Again, Tests and Unit Tests are a requirement for a professional team. But if you are programming games for fun, things are a litle bit different: How do you Unit Test how the laser shot look on screen? How do you Unit Test the 3D-Sound effect? How do you Unit Test the dificullty of a level. How do you Unit Test the flight patterns of your boids? How do you Unit Test Gamma Correct Lightning of your Fragment Shader? How do you Unit Test "Game Play"? ... I think you get the point. I consider all the above tests more important for a game than Unit Tests. Most of them require judgement by a human and if you are the only human in the project you have do do the test by yourself and this means testing every feature, constantly. Well, I was sure if I write "Don't do Unit Tests". I will get a lot of contra. ;-) It's a litle bit like saying "Jehova". I thought there will be enough "pro Unit Testing" comments, so my intention was to present a different view of the subject. Kind regards, Ralf 2010/3/11 Bob Kerns <r...@acm.org> > Ralf, I certainly agree that there are differences between lone-wolf > programming and for the large team. Scale, for one thing. > > There are also differences between being a 14-year-old beginner, who > may someday go on to be on a team, and a programmer with decades of > experience, who can afford to take some shortcuts. > > If you found your unit tests to be distracting noise -- my guess is > that they were, in fact, distracting noise. Rip them out! > > On the other hand, writing unit tests is a skill that requires > learning and judgement. A key component is to know just what to test, > and what NOT to test. > > It's a lot like comments. It doesn't pay to comment things that are > better said by the code. It also doesn't pay to write unit tests for > code which is unlikely to fail, and for which any failures will be > obvious. > > But if you've encountered a failure, and want to be sure it doesn't > happen again -- a unit test will help. It is best if unit tests are > integrated into your build process. > > If you're unclear on exactly what the contract for a piece of code > should be, writing a unit test first will help with that -- and again, > will help you verify that you've actually achieved that contract. > > Unit tests beat debugging obscure problems -- the single most > productive activity a developer engages is is debugging. And when you > DO need to debug -- a unit test can help you set up the conditions for > the failure, without having to go through a long setup cycle, or can > set up conditions which may be hard to reproduce in the actual > application. > > But if a unit test has no value, don't write it! If it ceases to have > value, discard it! > > (Which reminds me of a point I forgot to make: ABSOLUTELY, USE A GOOD > REVISION CONTROL SYSTEM! It makes discarding things safe...) > > A discipline of consistently creating well-chosen unit tests has other > benefits as well. One is that it leads you to structure your system > better. By making it so you can test elements of your system in > isolation, using mock objects, you get less coupling, and easier > development of those components. You can ensure that components work > before you combine them together into a system. > > Effective unit testing is a part of effective rapid development. You > certainly DO have to look at its effectiveness, and make changes where > it slows you rather than speeds you. > > But as advice to a young beginner, I think it's important to emphasize > that it's a skill that should be learned. > > I first became involved with teaching kids to program online back in > 1975, when as part of my undergraduate thesis proposal at MIT, I wrote > an online Lisp tutorial environment, featuring online interactive > lessons, online interactive and email assistance from human > volunteers, and collected thousands of session logs. I had all sorts > of students, from junior high school to NASA engineers. Many of my > younger students have gone on to quite successful careers - several > going to MIT and Harvard, at least one becoming a professor and > executive coach. > > One of the key things that made this little program successful, was > that it did a little setup, and then let you PLAY with different > things, until you understood them. It also CHECKED that you got the > result expected for the tutorial. > > You didn't need to write an entire application. You could play around > immediately, and for as long as you want, and get immediate feedback > as well. > > Unit tests, done right, restore a lot of this sense of play. Set up > the expected conditions, then play around with the approach, > interface, and implementation, and then put it to work in your > application. > > But one of the hardest areas to automate testing has always been user > interface. That's still true on Android (though it has facilities to > help), and a lot of apps are nearly 100% UI, with no logic to speak > of. The payoff may not be there in such cases -- but still, you want > to look for the short test/learn/improve cycle. Include an activity or > view you can just fiddle around with a new component, without having > to do a lot of setup or mess up what you already have working. > > Finally, back to your point, Ralf, about "you usually test the game > every 30 minutes". That should be a big red flag, as making testing a > prime target for automating and making efficient. If testing takes you > 10 seconds, there's not much to gain -- but when those tests every 30 > minutes start to take longer, or if you end up missing problems > because the testing you do ever 30 minutes isn't enough to uncover the > bugs -- then automating some of that testing starts to look like a > time saver. > > (BTW -- I haven't done it yet, but I've recently acquired everything I > believe I need to run that 1975 teaching application on my phone! I've > already got the OS running, and a friend dug out a snapshot of the > relevant directories. :) > > On Mar 11, 4:57 am, Ralf Schneider <li...@gestaltgeber.com> wrote: > > Hi Yahel, > > > > Well, I'm programming since 25 Years in various languages. I have written > > "demos" for the demoscene on 8 and 16 bit Computers. Have written two > small > > succesfull computer games. I have programmed as a freelances in different > > (big) companies. In my current job I'm still a developer by heart but > doing > > additionally architecture and technical project management "for the > > Enterprise". > > In my spare time I'm currently programming a game for the Android > platform. > > > > After all the years I realized to be sucesfull and to finish a project as > a > > lonely wolf programmer things are different than in the enterprise. > > It was necessary for me to "Go back to the roots". > > > > In my home grown "game framework" I have thrown out all "Unit Tests"! I > > consider it just distracting noise. > > I switched to an old programming style. Everything as staright to the > point > > as possible. > > > > For personal projects I have only a limited attention span. Usually after > > 6-9 Month I loose intrested in the project. > > So important goals for me are: > > - To keep the project small enough to get finished in this time span. > > - Do everything which keeps the project interesting and try to expand the > > 6-9 month time span. > > - Avoid everything which does not directly contribute to the project. > > > > => This means: Doing no Unit Testing! > > > > When you develop a game, you usually test the game every 30 Minutes. You > > test your new function. You check how the new fancy effekt looks like on > > screen. You test your new "weapon" which you have just finished > > implementing. You test the sound effects. You tweak the graphics. You > play, > > play, play and play the game over and over again. > > > > ...Serious bugs usually show up very quickly and usually I fix them > > immediately if I discover one. > > > > So, my recommedation for a beginner is: > > Keep it fun! It feels good if a new feature looks good on screen! The > > constant visuall feedback you get in game development can drive you > trough > > the project. > > If you don't like Unit testing. Don't do it! Concentrate on the game and > > game play. > > If you finish your project you will be judged by your game and not by > your > > source code and how much test coverage you have. > > > > This is just my very personal opinion. > > > > BTW: For projects consiting of more than three people things start to > look > > different. > > > > Kind Regards, > > Ralf > > > > 2010/3/11 Yahel <kaye...@gmail.com> > > > > > > > > > Hi everyone, > > > > > Not really Android specific but : > > > > > I've just read Bob Kern's answer to a vaillant 14 years old programmer > > > who wants to write a game for Android. > > > > > Bob's advice is good as always and he states : > > > "Learn how to test effectively. Use unit tests for as much of your > > > system as you can. Go to junit.org for more information. If you write > > > your tests first, you'll clarify what you want to do, and it all gets > > > much easier. But testing is also a skill that needs to be developed." > > > > > Now I've been a developper for 10 years, mostly solo works, and I have > > > never ever used UnitTesting, ever. Be it in VB, C++, PHP, ASP, Ruby > > > and now Android. > > > > > Do you guys really use it in your ANDROID apps at all ? > > > Do you really feel it makes a (significant) difference in your > > > code(app) in the end ? > > > > > From a conversation from the beginning of the week I'm now having to > > > learn the full xml RFC, so please don't try to hard to convince me, > > > I'm beginning to feel dizzy already :D > > > > > Sorry for the OOST. > > > > > Yahel > > > > > -- > > > You received this message because you are subscribed to the Google > > > Groups "Android Developers" group. > > > To post to this group, send email to > android-developers@googlegroups.com > > > To unsubscribe from this group, send email to > > > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com><android-developers%2Bunsubs > cr...@googlegroups.com> > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscr...@googlegroups.com<android-developers%2bunsubscr...@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
