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 <[email protected]> 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 <[email protected]> > > > > > 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 [email protected] > > To unsubscribe from this group, send email to > > [email protected]<android-developers%2Bunsubs > > [email protected]> > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
