As I mentioned in the previous post, this is mostly rewording and regurgitating what is already available on the internet, this is mainly for my own personal benefit as a refresher and exercise (As I had last used JUnit 3, but JUnit 4 is being used now), in this post I'll start an JUnit test, and later I'll do a C# one.

 The Android developer documentation is a good source to follow.  http://developer.android.com/training/testing/start/index.html

Local unit tests are tests run on your local machine without needing access to the Android framework or an Android device.  So we'll start with that kind.

Another kind is the Instrumented tests that run on an Android device or emulator, because they have access to an Android device, they can run as proper Android run tests (As if someone is actually interacting with the device), along with component testing.

I've also found out since then, that since version 1.2 of Android Studio, JUnit testing has become much much easier.  Earlier versions required some manual editing and adding of entries to build files.
For a more in depth look, Big Nerd Ranch had their own blog post about it.  https://www.bignerdranch.com/blog/triumph-android-studio-1-2-sneaks-in-full-testing-support/ (Be sure to read the updates at the bottom).

The whole process as described seems kind of backward, as you are kind of going out of your way to make code fail, when it is very easy to 'just make it work' from the beginning then check to see if it fails.  Perhaps I misread what others are meaning?

If you are going to write the test first...

According to the 'Uncle Bob's three rules of TDD' http://agileinaflash.blogspot.fr/2009/03/unclebobs-three-rules-of-tdd.html we are writing as little as possible to start with...this might leave some stuff up for interpretation, but for the sake of this test, I'll write as little as possible (and for demonstration purposes).

I want to test a Person object that I want to create eventually, so I create the test in the src/test folder path and set up just enough of a test to show that a function I want will fail (but will then later work).
Note: src/test is for local unit tests, and src/androidTest is for Instrumentation Tests, this is a local unit test (without need of Android stuff, just a vanilla Java class/method).



According to this test that I've written, I'll eventually be making a person object, and testing a method called 'getFullName', which will return "Donovon Heap", if they match, the test works.

But right now the object and method haven't been written yet, so we can't run the test.

Luckily IDE's are great for stubbing in what they think you want.  So lets do that.

With Person in the cursor, hit ALT+Enter




In this case since we are creating a class, make the selection.



Make sure you are putting your class in the correct location and package.



And boom, a class is created for you (Or, if you want to, you could write it yourself...whatever floats your boat).

But back in the test, we haven't implemented the getFullName() function yet, you can either use the ALT+Enter popup to create the method for you, or you can write it yourself...If you make it actually work as the test expects, then technically you are breaking the rules (as I read them?)...It seems kind of off putting to me, but it's up to you.

For this case, I'll make it fail anyways.




This will make the test fail, as it's not returning my name, but null, when the test runs, it'll fail.

One thing to check for in  Android Studio is make sure the Build Variant is set to Unit Test, if It's set to Android Instrumentation Tests, you'll notice that the project tree changes a bit and toggles the src/androidTest and src/test from a 'selected' state.



Now, if you want to manually run the test, you can right click on the method and select 'Run (method name)'.





And boom, our test fails.




So now lets fix our method to pass the test.
At this point, if they literally mean as little as possible to pass the test (even if it means hard coding it), this might be what they mean.



Now when we run the test, it should work.



Now as we continue on with building code and implementation, we can continue to run this test and make sure Person.getFullName() stays working.

If you are adding a unit test to an already existing method...

If the case may be that you are maintaining code, and want to add a test to a function as written (in this case we will use the above code as what we are going to add a unit test for).

ALT+Enter on the class you want to add a test for and select the 'Create Test' entry.

Make sure you are selecting the methods you want to have generated, and on JUnit 4.

Now all that is left is to write the actual test code. (see above for actual code you'd put in the testGetFullName() block).

Depending on if you are 'sticking to the letter of the law' when following the rules, or bending them by adding 'shortcuts' (I may have by adding "Donovon Heap" as the test resultant depending), the general idea seems to be worthwhile to me.  If you get into the habit of writing tests first before actual implementation in general, it makes life later on easier.

You'll think of the debugging process differently to be sure as you're forced to think about what you're going to do, vs what you've already done.

This is also how to run basic Local Unit Tests in Android Studio with a person behind the computer...with a proper build system you would probably run Unit Tests through the command line during builds or source code commits, https://docs.gradle.org/current/userguide/tutorial_gradle_command_line.html

Next Up, C# in Visual Studio.

In the series of posts I'm making, I'll make some simple Unit Tests for C# and Java (specifically with Android Studio Instrumented and Local Unit Tests)...Mainly for my own benefit as it has been awhile since I've been able to unit test and some things have changed, and It's good to try and explain concepts for your own personal understanding.  Maybe even with communication skills.

To start off with...

As it has been awhile since I've done an Android Unit Test, I thought I'd do myself the favor of using this old blog to refresh my memory and see what new tools and patterns are in vogue.  It's mainly a regurgitating of what I see online, but it helps me crystallize in my mind what I'm reading.

 Quick refresher, a Unit Test is a ..."automated piece of code that invokes a unit of work in the system and then checks a single assumption about the behavior of that unit of work".

 As a coder writes code, they make bits and pieces of code, each does something special individually, they work together and when they run together as a program or application something you wanted to happen, happens. If he/she does it correctly the code works and nothing bad happens and if you leave it at this, you are left with fewer problems.

 Issues at this point are usually from the outside considered pretty basic and logical as a general style and understanding, as you write to get to the point where the program is complete, you may make mistakes and as you keep writing you fix issues that you mistakenly put in as you are building the program for release.

 After release is a whole new ball game as maintenance kicks in, and changes are made to the code...at this point to make sure the program is still working as intended, the belief is that you basically 'test everything' to make sure no side effects have taken place (I changed this piece of code here...and it ended up making a mistake over here...the 'Butterfly flapping it's wing' effect).

 Add in more than one coder and the problems become even more compounded.

 But recently a new trend seems to be making the waves and catching on like fire, it's fairly old philosophy, but everyone seems to be loving it now...It's called Test-Driven Development (TDD) https://en.wikipedia.org/wiki/Test-driven_development and it kind of throws what would seem like common sense, out the window, but actually makes sense when you dig in a bit.

  A core principle of this philosophy is the 'Unit Test'...  (Note Unit Test is different than other testing patterns...Integration, Regression, etc...see this post for more info http://stackoverflow.com/questions/520064/what-is-unit-test-integration-test-smoke-test-regression-test )

 If you are working on 'New Development', not 'Maintenance'...(But you can add in Unit Tests as you are maintaining even without having have to start with the pattern already in place, you can add it, I'll try and get to that later).

 The first thing you do when writing a piece of code (before it actually does anything), is to write a test for it.

 And the first test you run, should fail.

 Common sense would say, 'But you can't test something that doesn't do anything?', or 'But what will you test?  Why not wait until the end when it's finished'

Wikipedia has a good write down on why it's considered good practice, so I'll leave that there https://en.wikipedia.org/wiki/Test-driven_development#1._Add_a_test

 Basically it makes you think ahead about what you're going to do, what the requirements are. You want it to fail so that you know the test harness is working...if it doesn't fail and you haven't actually done anything, then something seems off.  (If there's no chickens in the hen house, I'd start looking for a fox). 


 For Android (or Java in general), the most popular and widespread Unit Testing framework one is JUnit.

 Android has some support libraries that make life easier, which I will get to later.

But next up, lets decide on something we need, write a test for it, and make it fail!  (Coming next blog post)