Develop Reference

Android - Kotlin - JUnit 5: How to test private methods?

General software organization question:
I have a Kotlin class file (under src/) with some 10 methods, only 1 of which should be visible outside the class (the rest should be private).
I also have a dozen JUnit test methods for testing the abovementioned methods, and I put all those in a different class file (under src/test/).
But the test methods cannot see the methods they're supposed to test, so I had to remove the private modifiers from the source code :(
What's a man to do?
JUnit 5, Kotlin for Android, on IntelliJ, if that matters.
Thank you

What's a man to do?
Check this question and answer.
Either a) test the private details indirectly by testing the public interface (which goes through the private methods) or b) Use #VisibleForTesting annotation to make a private function public for testing but clearly flagged as something that should not be used otherwise.

Inheritance of TestCases on Android

I was wondering if it was good practice to subclass the test cases on Android. I mean, I need to test a lot of Parcelable objects and I could create a class like GenerericParcelableAndroidTestCase to test all these objects.
I also have a problem implementing it, I have something like this:
public class GenericParcelableTest extends AndroidTestCase {
private Parcelable p = null;
GenericParcelableTest(Parcelable p) {
this.p = p;
}
public void testDescribeContents() throws Exception {
assertEquals(0, p.describeContents());
}
}
And that:
public class AttachmentTest extends GenericParcelableTest {
public AttachmentTest() {
super(new Attachment());
}
}
Attachment implements Parcelable of course.
It returns me this error:
junit.framework.AssertionFailedError: Class GenericParcelableTest has no public constructor TestCase(String name) or TestCase()
I mean, I know that I created no empty constructor but why would I need one?
And generally, is there some known issues with this approach? If not why is there very few article on this topic on the internet (and actually some say even that it's not a good idea).

I have this conversation quite often when introducing new team members to unit testing. The way I explain it is by stating that your tests are first class citizens of your code base (no pun intended), they are susceptible to the same technical debt as any other part of your code base and have equivalent (maybe more?!) importance as that of the runtime code.
With this mindset, the questions begins to answer itself; if it makes sense from an OO perspective to use inheritance (i.e. your subclass is a insert name of test superclass) then subclass away. However, like any abuse of inheritance ever, be careful...the minute you add a test case that doesn't rely upon that superclass behaviour you may have a code smell.
In this scenario, it's likely (perhaps 90% of the time?) it is a separation of concern issue within the code being placed under test, i.e. the "unit" under test isn't actually (one) unit but has combinatorial behaviour. Refactoring that code to do one thing would be a good way of allowing your super-class test case to live on. However, watch this super class test case like a hawk...the minute you see booleans being added to signatures to "allow that similar but not the same" test case to run under your once unpolluted super class then you have a problem, a tech debt problem that is no different to your runtime code.
At last check AndroidTestCase depends on an Activity context so it's likely best described as an integration test which tend to regularly have boilerplate super-class test behaviour. In this case, try to narrow the focus of your superclass to the use case under test...i.e. extends LoginUseCase or extends LoginScenario to better "bucket" those subclasses in the first instance. This will help guide would be extenders as to whether they should be using it for their non-login scenario. Hopefully, conversation will ensue and tech debt accumulation be avoided!
Regarding your error, in JUnit3 do what #Allen recommends, if moving to JUnit4 with something like Robolectric then explore using Rules as well as #BeforeClass.
Personal note
I have only felt the need to write test super classes for pseudo-unit tests that mock an API end point (akin to MockWebServer if you are familiar with that product) and DAO integration tests whereby an in-memory db is started and torn down over the lifecycle of each test (warning - slow (but useful) tests!)

junit.framework.AssertionFailedError: Class GenericParcelableTest has no public constructor TestCase(String name) or TestCase()
You get this error because JUnit needs to be able to construct an instance of your test class. It only knows how to do this using no-arg, or single string constructors.
Instead of performing initialization in your constructor, you should put it in the setUp() method. This will let you use the default constructor while still initializing the object before the test method is called.

Cannot reference class from another class in same package

I'm admittedly new to Scala and Android programming and in all my searching I haven't been able to find answer to help me understand and resolve my problem.
Here's a gist of my two scala classes https://gist.github.com/Daikamar/f15288a7bf732cd5b55c
I'm running through the tutorial found here: http://developer.android.com/training/basics/firstapp/starting-activity.html
which I'm trying to adapt to scala code (I have need for understanding Scala for work and a personal desire to mess around with Android development so I figured I'd try and combine these efforts).
The problem is seen in DisplayMessageActivity.scala in which the IDE reports that it cannot resolve MyActivity in this line:
val message = intent.getStringExtra(MyActivity.ExtraMessage)
I feel like this should work. I can get it to resolve if I change MyActivity to an object, but then that breaks other pieces of the application that expects MyActivity to be a class.
An help in getting me to understand my problem would be appreciated.

You cannot reference the ExtraMessage field from MyActivity as though it was a 'static' field (in Java terminology). To access ExtraMessage in your other activity you will need to either obtain an instance of MyActivity that you can then de-reference, or add a companion object (defined using the object keyword in the same file in which the class is defined) for MyActivity and define the field there:
object MyActivity {
val ExtraMessage = "net.daikamar.myfirstapp.MESSAGE"
// any other 'static' declarations
}
class MyActivity() extends ...
then your call as above will work.

method in android which can be accessed from anywhere?like modules in VB

I am new to android. If my question is wrong please forgive me,
My Question is:
Can I write a method in android which can be accessed from anywhere inside my application?
I've studied VB for all these years and now I am trying to program in android, I couldn't stop comparing them when I write code.
In VB we can create modules and access it from anywhere. Is there anything I can do in Android...??
Answers and advises are needed!

You have to create a class with a static method:
public class MyClass {
public static void myMethod() {
// Your code here...
}
}
And you can call it like this: MyClass.myMethod();

You can try extending Application and put your common functions there.
In all activities you can access this via context.
For reference follow this:
http://www.devahead.com/blog/2011/06/extending-the-android-application-class-and-dealing-with-singleton/

It is a long topic to discuss , but as you have simply ask whether method is accessible or not , then answer is yes but with some respect of java rules.
Android is again like java coding, You can do same thing what we can do with java.
Same Data type
Method Format
Class structure
Inheritance, Public , private , protected, etc.
So while you write your code you should care for that all things and these all thing you know because you are working in VB.

VB module equivalent is not there in java(android),
but some how you can mock them to some extend by using final classes with static methods.
Anyway you need to import the package containing these type of classes wherever you use it.

Static class in Java (Android) - use or not use

Recently I have started development in Java for Android.
My idea is to create one static class which will load ton of stuff on the beginning and store results for a lifetime of application.
I have been reading lot of how to share object between activities and I think the best will be to create one static class. What do you think? Should I use another approach? I am asking because I have read lot of counter opinions over the internet.
Thank you.

I'm assuming that you were referring to static fields of a class, as opposed to static class which, as Wyzard pointed out, is something completely different. As a general rule of thumb, holding information in static fields is not a good idea in Java. The reason for this is that it prevents the ability to instantiate multiple instances of whatever it is you store in the class.
In the specific case of an Android application, the best way to deal with the issue of having data stored associated with the application itself is to subclass the android.app.Application class and use it to handle application-global data:
class FooApplication extends Application
{
private String privData;
public String getPrivData() {
return privData;
}
}
You then need to declare that this class is your main application class (instead of the default Application). In the application entry in AndroidManifest.xml add the following:
<application android:name="com.example.application.FooApplication"
...>
...
</application>
You can then look up the application instance from anywhere inside your application using the method Context.getApplicationContext() which will be an instance of your Application subclass:
FooApplication app = (FooApplication)Context.getApplicationContext();
String privData = app.getPrivData();
Depending on from where you are trying to look for subclass of "Application", you may have to invoke the "getApplicationContext()" without "Context":
FooApplication app = (FooApplication)getApplicationContext();
String privData = app.getPrivData();

The problem with your solution is that you're basically creating a huge stack of globals. It's sometimes unavoidable, but it has the same type of problems globals always have- you quickly end up with hard to read code that doesn't really have a good OO breakdown. You can use this, but use it sparingly- only with important data structures that are really going to be shared between many activities.

Android provides a class called Application, which is will not be gc'ed as long as your Application isn't killed. Use this class for initialization, static classes as containers are somewhat ugly, but i can't pinpoint why that is.
I only use them as containers for constants such as bitmasks which can't be expressed as EnumSets.
As the other posts mention SharedPreferences: I think the preferences exist to store values, but not to load your structures that you need for you application. These structures should be loaded from a construct that represent or make up a model for your data's semantics.