I would like to ask something interesting. When I am developing native android apps,and want to make sure that there no null objects,I use the debugger as shown.
So I put a break point in the line I want,I step over my code and the fun begins:). However,there is this TDD,which I have never used. Are they any specific tools for that? Is it more efficient?
Regards,
Theo.
TDD is generally a better approach as it stands for Test Driven Development and its idea is to have reproducable tests to validate your code against. A good way to do so is to read youself into JUnit which is also included in Android Studio.
EDIT: Also TDD is generally more Efficient as you notice errors much earlier and you write better code
Related
I'm working with Android in Netbeans and trying to decide which testing framework to implement for my application (I've never done TDD in Android before). I've been using this thread to look into different resources. I'm mainly familiar with whitebox, so I feel that I would be more comfortable with the built-in Instrumentation Framework. However, this is the first time I've heard of blackbox testing (Robotium), but it looks like it would be really useful as well. Is it common practice to implement both whitebox and blackbox tests? Or is only one really necessary? If both, what things are best to be whitebox tested and which are best to be blackbox tested? Or is this a totally useless question as it's completely application dependent and I should just pick one and start messing with it?
[EDIT]: I also want to add that I don't have any experience with JUnit since a lot of explanations seem to assume a basic understanding of it.
The two options you suggest (Instrumentation and Robotium) are actually pretty much the same thing, the closes to whitebox (or true tdd/unit tests would probably be roboelectric).
Is it common to do both? Yes i think that is usually a good approach normally you want to test things as low down as possible and then have fewer of the big blackbox tests, android doesn't make this the easiest if you ask me though so you may have more luck with the instrumentation/robotium tests cases as these are fairly easy to understand and they match up with what you can see on the screen fairly easily.
With regards to junit, android is bundled with junit3 which has much less features/complexity as jUnit4, and for the most part the only thing you will need to know is to name your testmethods with the word "test" in front of it e.g. public void testXXX().
I have googled about testing uni and systematic testing. But I am confused what exactly is systematic testing? I’m developing a mobile app and like to know how I can approach this technique testing.
Any ideas? Thanks in advance.
Systematic testing is a much more exhaustive means of debugging software. The goal is to test the software against a variety inputs in order to find as many defects/errors as possible. The difficult part about systematic testing is usually coming up with the inputs/situations to test against (especially in the case of Android development, as a number of things can go wrong). Does your app work correctly after configuration changes? Do your EditText boxes specify the correct inputType? Systematic testing provides a means of uncover such errors, and often results in a more secure/robost application.
The Android team provides several tools that can automate this kind of testing (although obviously there is no guarantee that it will cover ALL of the cases). One such tool is monkeyrunner. Check out the Android developer's guide on testing for more information.
A systematic test is a test, in which
the setup is defined,
the inputs are chosen systematically,
the results are documented and evaluated by
criteria being defined prior to the test
Knocking my head against the wall trying to figure out a good workflow for sharing code between a few WP7, iOS, and Android applications, all implemented in .NET/Mono. Anyone has figured this out?
I have some experiments in code sharing that you can see here: http://granite.codeplex.com/
What I've learned so far:
Pure business objects are your best friend. Pushg as much logic as possible into these.
Testing frameworks on mobile devices are just about useless, but you can unit test the heck out of your business objects using the desktop platforms (.NET or Mono).
Mono has more bugs that .NET, so make sure you run your unit tests against it.
Make sure you use a source control that works with MonoDevelop. That means no TFS.
Make sure you use a Unit Test framework that Mono supports. (e.g. NUnit)
View-models can be shared with the right abstraction layer, but it may not be worth it.
I use SVN in order to code in Mono on PC/MAC/LINUX - tho i rarely do anything on Linux other than POC's.
As far as workflow for sharing libraries between all of these different systems - good luck. All i can offer is:
- Be sure to unit test as Jonathan pointed out
- Know all of your compiler hints that are available
- Avoid P/Invoke or any O/S specific calls if possible
- Pray
Good luck :-)
I am a newbie to android. And feels like TDD can reduce developing time a lot. But after learning android's junit test framework, find it a bit difficult to achieve the goal that write test before coding. Especially when i want to test module like adapters, views and databases. So i wonder it's because i am not familiar with android test framework enough or android is not suitable for TDD.
Sure.. :-) In general TDD approach can be used for developing Android apps too. But not always worth.
It sometimes needs more effort, so you should consider the pros and cons carefully. I think you should not force to do every little part of your development process to be test-driven, but consider using it every time before you start typing. I prefer mixing TDD with test-last approach.
You can try by using robolectric https://github.com/pivotal/robolectric
and here is sample https://github.com/pivotal/RobolectricSample
It can't be done in the AppInventor, yeah?
Just want to make sure before i go off learning all about Java Programming.
Thanks
Well, given this link, it sounds like Bluetooth is possible via AppInventor;
https://sites.google.com/site/appinventorresources/home/tutorial-topics/bluetooth
I havent used AppInventor but if you dont have Java knowledge and arent desperate to learn how to program I think it would be worth trying it, especially if you are keen to get your app built sooner rather than later.
Bear in mind that the implemented BT capability in AppInventor might be quite limited.
some more resources:
http://groups.google.com/group/appinventor/browse_thread/thread/43aa635f1721899b
http://www.google.com/url?sa=D&q=http://ai.kittywolf.net/index.php/BTArduinoLED1&usg=AFQjCNGQ4HG_IYNLdauyEYEafnUhEJVJBg
AppInventor isn't capable of doing such things. AppInventor isnt developed anymore so i think it will never be able to do such things aswell.
Android development is not restricted to be done in Eclipse.
You can program in other IDE's or even from command line.