[android-developers] Re: Unit Testing : Who uses it ?
On Apr 23, 2:35 pm, Gubatron gubat...@gmail.com wrote: I've come to use Unit Tests organically. Certainly I don't write unit tests first, I write tests to make sure what I've coded works the way it's supposed to. I also add more tests whenever I find bugs. Of course not everything can be unit tested, but most things can be. I found jmockit ( not to confuse with jmock!) extremely usefull in creation of unit tests. It can easily mock interactions with any android objects, and even superclasses of my activities so I can unit-test them -- 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
[android-developers] Re: Unit Testing : Who uses it ?
I find that most of my problems are device or user specific issues. So to be useful, the unit tests would have to run on the actual hardware used by consumers, and would have to emulate the behavior of real users. Years ago, when I had to write a small bit of generic java code for server side logging, reporting, and metrics, that was going to be used for lots of different purposes, we used test driven development, and I was glad for the experience. So basically, I suggest you use the right tool to ensure the right level of quality for each specific project. On Mar 11, 1:36 pm, DulcetTone dulcett...@gmail.com wrote: I routinely find a disproportionate number of my bugs and crashes reside in the code set up for the purpose of testing and evaluation of the program rather in the function of the program itself. I'm sure this is a measure of my unfamiliarity with best practices, but I find it more beneficial to try to write crash-detection-and- reporting code rather than explore testing. That said, I am not inspired to look at junit.org tone -- 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
[android-developers] Re: Unit Testing : Who uses it ?
Writing unit tests first to define exactly how a program will work is nice if you have the luxury of knowing exactly how the program will work ahead of time! I often have a general structure for a program (game) but I don't have all the little details figured out because things don't always go as planned. What if I write all my tests for a quadtree data structure and put in weeks of development only to find out that the quadtree is not fast enough or eats too much memory? Instead, I take the approach of working on the features that commit me the least to a certain way of doing things. And I only write parts of an application when I need them, not before. This eliminates much of the waste that happens when you do an about face in terms of the way your app works. Front loaded unit testing violates my rule, so I don't do it. On Apr 21, 2:27 pm, Matt Kanninen mathias...@gmail.com wrote: I find that most of my problems are device or user specific issues. So to be useful, the unit tests would have to run on the actual hardware used by consumers, and would have to emulate the behavior of real users. Years ago, when I had to write a small bit of generic java code for server side logging, reporting, and metrics, that was going to be used for lots of different purposes, we used test driven development, and I was glad for the experience. So basically, I suggest you use the right tool to ensure the right level of quality for each specific project. On Mar 11, 1:36 pm, DulcetTone dulcett...@gmail.com wrote: I routinely find a disproportionate number of my bugs and crashes reside in the code set up for the purpose of testing and evaluation of the program rather in the function of the program itself. I'm sure this is a measure of my unfamiliarity with best practices, but I find it more beneficial to try to write crash-detection-and- reporting code rather than explore testing. That said, I am not inspired to look at junit.org tone -- 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 athttp://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
[android-developers] Re: Unit Testing : Who uses it ?
Well, except that you should apply your rule to unit tests, too. I'm not sure why you'd put in weeks of development on a quad tree, and not write tests for it. But if there's a question about whether you want to be spending weeks of development on a quadtree implementation, a simple implementation and a unit test to drive it and measure its memory usage and performance would seem like a wise precaution to me. But really, weeks of effort on a quad tree? Or even a K-D tree? That doesn't quite make sense to me. I'd guess it was a quad tree, and a lot of functionality built around the quad tree? I wouldn't commit more testing effort than I would coding effort. Write a unit test for what you're about to write. NOT for an entire API! Test-first programming does NOT mean you write all your tests before you start coding. That's not at all agile, and you're quite right to reject it. But that's not what's meant by test-first programming. And my experience is, done right it saves a lot of debugging time. On Apr 21, 1:18 pm, Warren warrenba...@gmail.com wrote: Writing unit tests first to define exactly how a program will work is nice if you have the luxury of knowing exactly how the program will work ahead of time! I often have a general structure for a program (game) but I don't have all the little details figured out because things don't always go as planned. What if I write all my tests for a quadtree data structure and put in weeks of development only to find out that the quadtree is not fast enough or eats too much memory? Instead, I take the approach of working on the features that commit me the least to a certain way of doing things. And I only write parts of an application when I need them, not before. This eliminates much of the waste that happens when you do an about face in terms of the way your app works. Front loaded unit testing violates my rule, so I don't do it. On Apr 21, 2:27 pm, Matt Kanninen mathias...@gmail.com wrote: I find that most of my problems are device or user specific issues. So to be useful, the unit tests would have to run on the actual hardware used by consumers, and would have to emulate the behavior of real users. Years ago, when I had to write a small bit of generic java code for server side logging, reporting, and metrics, that was going to be used for lots of different purposes, we used test driven development, and I was glad for the experience. So basically, I suggest you use the right tool to ensure the right level of quality for each specific project. On Mar 11, 1:36 pm, DulcetTone dulcett...@gmail.com wrote: I routinely find a disproportionate number of my bugs and crashes reside in the code set up for the purpose of testing and evaluation of the program rather in the function of the program itself. I'm sure this is a measure of my unfamiliarity with best practices, but I find it more beneficial to try to write crash-detection-and- reporting code rather than explore testing. That said, I am not inspired to look at junit.org tone -- 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 athttp://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 athttp://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
[android-developers] Re: Unit Testing : Who uses it ?
I've been a professional programmer since 1975. A lot of my programming was done without unit testing. I now think that was a mistake. I'm fond of saying that programming is both really easy and impossibly difficult. Testing is a good example of this. But it depends on the size and complexity of what you are trying to do. There is a size of program that can be successfully written without them. And if you are the only consumer of the code you write, it's less important. But here's the thing. If I come back to code six months later or a year later, I might forget all the requirements of that code. I might forget where one change I made affects other things. If I have a good test suite, that memory loss will show up as a test failure. And when problems that are exposed at the time they are made are inherently easier to fix. But if I'm writing demos, scripts, or 1000-line one-offs, that never happens. So it isn't worth it.Big, complicated systems should never be done without them. I've done it, and I regret it. I've known those places in the code that I don't want to touch, for fear of breaking things that would take days to sort out. Since then, I've used unit testing on medium sized projects and love it.A really solid set of unit tests lets you feel much more free to refactor constantly.So those nasty places cease to exist. -- 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
[android-developers] Re: Unit Testing : Who uses it ?
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.
Re: [android-developers] Re: Unit Testing : Who uses it ?
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
[android-developers] Re: Unit Testing : Who uses it ?
I routinely find a disproportionate number of my bugs and crashes reside in the code set up for the purpose of testing and evaluation of the program rather in the function of the program itself. I'm sure this is a measure of my unfamiliarity with best practices, but I find it more beneficial to try to write crash-detection-and- reporting code rather than explore testing. That said, I am not inspired to look at junit.org tone -- 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
