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)