Quantcast

Maximum PC

It is currently Wed Dec 17, 2014 7:05 pm

All times are UTC - 8 hours




Post new topic Reply to topic  [ 13 posts ] 
Author Message
 Post subject: My first app
PostPosted: Thu Oct 06, 2011 11:26 am 
8086
8086

Joined: Mon May 02, 2011 6:50 am
Posts: 51
Hello Maximum PC community!

I just made my first app for android, and was trying to get people to give me some thoughts about it.

It's a calculator that uses text-based expressions rather then button-press actions. I'm not too sure if the forum rules would allow me to post the link here (although the app is free).

If you want to try it, just search android market for com.math.scalc
Thank you.
Hexorg.


Top
  Profile  
 
 Post subject: Re: My first app
PostPosted: Fri Oct 14, 2011 11:56 am 
8086
8086

Joined: Fri Oct 14, 2011 11:41 am
Posts: 5
Great Work.


Top
  Profile  
 
 Post subject: Re: My first app
PostPosted: Wed Oct 26, 2011 7:45 pm 
Team Member Top 50
Team Member Top 50

Joined: Sat Jun 25, 2005 11:04 am
Posts: 1026
It looks good.

One thing that I noticed is your scientific notation is error prone. If the input is anything other than #e# (# is a number), the program crashes. At a minimum you should indicate that the input is invalid (not crash). I'd say it should also accept e# (i.e. 1e#).

It'd also be nice to have a hexadecimal conversion function, nth root function (take the arbitrary root of a number), and log base 2 function (or arbitrary base).

Look forward to see where this goes.


Top
  Profile  
 
 Post subject: Re: My first app
PostPosted: Mon Oct 31, 2011 9:35 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 987
Location: Earth
mag wrote:
It looks good.

One thing that I noticed is your scientific notation is error prone. If the input is anything other than #e# (# is a number), the program crashes. At a minimum you should indicate that the input is invalid (not crash). I'd say it should also accept e# (i.e. 1e#).

It'd also be nice to have a hexadecimal conversion function, nth root function (take the arbitrary root of a number), and log base 2 function (or arbitrary base).

Look forward to see where this goes.


If you can post source code, we can help you go through it (I think it's in Java, right?). If mag's putting invalid data into your app and it crashes, then you're not putting in validation. Did you create tests for these? You should be checking for the following:

1. Invalid input
2. Null values (since Android dev is done in Java)
3. Null values as parameter arguments

These things break apps quick, if you want us to go and review your source, we can but you gotta post it. :)


Top
  Profile  
 
 Post subject: Re: My first app
PostPosted: Mon Oct 31, 2011 1:10 pm 
8086
8086

Joined: Mon May 02, 2011 6:50 am
Posts: 51
Thank you for feedback :)
DJSPIN80, I don't mind posting the code, but I know how to fix it. I had GRE past friday, so I just didn't have time to work on this app. Expect update soon :)


Top
  Profile  
 
 Post subject: Re: My first app
PostPosted: Mon Oct 31, 2011 6:57 pm 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
DJSPIN80 wrote:
Did you create tests for these?
:roll: You and your tests! You'd be happy to note that I wrote an error logging/email library and put a couple tests in it! However you'll be sad to note that we aren't deploying the tests with the library :)

To the OP: Data validation is a must though. The biggest issue I see facing mobile developers is the random crashing that seems to plague apps that would otherwise be really useful. I have uninstalled many an application because it was not validated properly and became unusable. It often made me wonder if anybody actually tested it before they released it to the wild.


Top
  Profile  
 
 Post subject: Re: My first app
PostPosted: Mon Oct 31, 2011 7:08 pm 
8086
8086

Joined: Mon May 02, 2011 6:50 am
Posts: 51
Quote:
It often made me wonder if anybody actually tested it before they released it to the wild.

Well my "company" of android developers consists of one (me) lol. I tested it and cleaned quite a lot of errors. But not all of them. That's why this app is still marked as version 0.8
... I'm kinda using users as beta testers


Top
  Profile  
 
 Post subject: Re: My first app
PostPosted: Mon Nov 07, 2011 11:59 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 987
Location: Earth
CrashTECH wrote:
DJSPIN80 wrote:
Did you create tests for these?
:roll: You and your tests! You'd be happy to note that I wrote an error logging/email library and put a couple tests in it! However you'll be sad to note that we aren't deploying the tests with the library :)

To the OP: Data validation is a must though. The biggest issue I see facing mobile developers is the random crashing that seems to plague apps that would otherwise be really useful. I have uninstalled many an application because it was not validated properly and became unusable. It often made me wonder if anybody actually tested it before they released it to the wild.


And this is why we test. :P

Honestly, I don't understand why Unit Testing was never really part of my workflow. Being able to test code coverage is a wonderful thing. Especially if you work in a statically typed language like C# or Java (being used for Android) or eve objective-c is a must. All you have to do is create mocks (or fakes) that mimic those objects that you need to test and test it. By verifying that your code does exactly what it's doing plus being able to test for edge cases like null values. It's not imperative yuo reach 100% code coverage but if you're testing with code coverage in mind, then you can verify that your code behaves as it should.


Top
  Profile  
 
 Post subject: Re: My first app
PostPosted: Fri Nov 11, 2011 12:56 pm 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Unit testing I get. Mocking I don't. Why spend time writing "fake" objects? Why not just write the actual ones? Wouldn't mock objects invalidate your testing because didn't build it for the actual objects?


Top
  Profile  
 
 Post subject: Re: My first app
PostPosted: Sat Nov 12, 2011 4:30 pm 
Team Member Top 100
Team Member Top 100

Joined: Fri Sep 17, 2004 5:35 pm
Posts: 1176
Sorry for hijacking your thread, Hexorg. To be honest I haven't looked at your app, but I'm glad to see that you're learning by doing -- that's the only effective way to learn.

DJSPIN80 wrote:
Honestly, I don't understand why Unit Testing was never really part of my workflow. Being able to test code coverage is a wonderful thing. Especially if you work in a statically typed language like C# or Java (being used for Android) or eve objective-c is a must. All you have to do is create mocks (or fakes) that mimic those objects that you need to test and test it. By verifying that your code does exactly what it's doing plus being able to test for edge cases like null values. It's not imperative yuo reach 100% code coverage but if you're testing with code coverage in mind, then you can verify that your code behaves as it should.

Reading this scared me so much I logged in to post a response! Code coverage is not a good test suite quality metric. In fact, it's an outright dangerous one.

The statement that "if you're testing with code coverage in mind, then you can verify that your code behaves as it should" cannot be more wrong, and I'm really frightened to see a skilled, experienced software engineer be lulled into such a false sense of security.

Many bugs do indeed lie in simple corner cases, and complete code coverage will find a lot of bugs. But really, this does not verify your code behaves as it should. Take the following (extremely simple) example:
Code:

void bar_1(){         
     lock(&something);    
}      

void bar_2(){
     lock(&something);
}   

void foo(){   
     if(a) bar_1();      
     if(b) bar_2();         
}

See the problem? You can have a test suite which has 100% code coverage and yet will still never encounter the deadlock. I think code coverage is such a bad metric not because it potentially leaves so many bugs uncovered, but because it leaves some bugs uncovered and draws programmers into incorrect conclusions about their code's correctness.

A better metric would be feasible path coverage, i.e. the percentage of feasible paths through a program's CFG which are covered by the test suite. Of course, this has its own problems. For one, it's extremely difficult to quantify the number of feasible paths, and determining whether a single path is feasible can be an intractable problem (probably the biggest reason it isn't used as a metric). For two, the number of feasible paths generally grows exponentially with the size of the program, making it infeasible to generate, let alone manually develop, a large enough set of tests to obtain any significant path coverage. And finally, it's also an unsound metric; 100% feasible path coverage does not imply the absence of any bugs, or even the absence of simple bugs like OOB errors:
Code:
#define S_MAX 256      
#define SMAX 128      
void foo(int s, int data){   
    char buf[SMAX];      
    //...         
    if(s < S_MAX){      
        buf[s] = data;   
    }         
    //...         
}   

This is a perfectly plausible bug which could be missed even by test suites with 100% feasible path coverage. Even worse, it's potentially exploitable.

Anyway, I got off on a tangent. My point was simple. Test suites are a good idea. Test suites with 100% code coverage are an even better idea. Test suites with 100% feasible path coverage are a pipe dream, but an even better idea still. Yet none of them provide verification of your software.

Back to occasional lurking... sorry again for hijacking your thread, OP.


Top
  Profile  
 
 Post subject: Re: My first app
PostPosted: Sun Nov 13, 2011 7:47 pm 
SON OF A GUN
SON OF A GUN
User avatar

Joined: Mon Nov 01, 2004 5:41 am
Posts: 11605
Kybo_Ren wrote:
Back to occasional lurking... sorry again for hijacking your thread, OP.
You and I both need to post more...


Top
  Profile  
 
 Post subject: Re: My first app
PostPosted: Mon Nov 14, 2011 10:38 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 987
Location: Earth
Quote:
The statement that "if you're testing with code coverage in mind, then you can verify that your code behaves as it should" cannot be more wrong, and I'm really frightened to see a skilled, experienced software engineer be lulled into such a false sense of security.


True, if you base your perception on code coverage alone. Pardon my semantics, and I agree with you that code coverage is not the way to go, I meant that code coverage should be based on meaningful tests. Testing for behavior, not simply blocks of code.

Quote:
Many bugs do indeed lie in simple corner cases, and complete code coverage will find a lot of bugs. But really, this does not verify your code behaves as it should.


This is why I'm a big proponent of meaningful tests. I don't believe testing for LoC coverage unveils anything, it creates a false sense of security. That's like creating a bridge and testing the strength of the arch by the amount of concrete you poured in. It's not a reliable test until you really plug away at trying to destroy it.

Also, a lot of bugs do lie in simple corner cases but code coverage tests doesn't unveil them at all. It's about validating behavior and your test should reflect that. When your code is "moving" per se, then you can really start to see where the null values come up, or when an exception is thrown.

Anyways, I should have clarified what I meant, I'm 100% agreeing with you so that's my bad. :P


Top
  Profile  
 
 Post subject: Re: My first app
PostPosted: Mon Nov 14, 2011 10:43 am 
Bitchin' Fast 3D Z8000
Bitchin' Fast 3D Z8000
User avatar

Joined: Mon Jun 14, 2004 4:04 pm
Posts: 987
Location: Earth
CrashTECH wrote:
Unit testing I get. Mocking I don't. Why spend time writing "fake" objects? Why not just write the actual ones? Wouldn't mock objects invalidate your testing because didn't build it for the actual objects?


Depends. Faking/mocking honors the service boundaries of your application. Unit testing is supposed to validate that the behavior you coded against is validated. You're not int he business of testing the entire stack, just the calls you're making. This is where faking/mocking comes in. If your business logic pulls data from a service (whether it's an ASMX or WCF or SOAP service), you don't care. Fake the service, return the values you expect and test the behavior. You can get real granular because you can start plugging away invalid values as well. By doing so, you're isolating the behavior of your code thus you can see how your code actually behaves. The minute you start extending your tests to include the database, web service calls, etc...you've done integration testing.

Also, you don't have to write fake/mock objects. You can use a tool like Moq, RhinoMocks or FakeItEasy (all in .NET).

This reminds me, are you testing against interfaces or concrete classes? As much as possible, I really go the distance and pass around interfaces rather than concrete objects. This way, every layer of my application is testable.


Top
  Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 13 posts ] 

All times are UTC - 8 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group

© 2014 Future US, Inc. All rights reserved.