On my last project, I managed a team developing an application to manage hospitality locations. Given our requirements were constantly in flux, the contracts were on a short cycle, and the team was generally new to enterprise software development, I chose a Kanban style approach to managing and delivering it. I wanted to share with you the rationale, methodology, challenges, and the surprising change to my role while on the project.

Why Kanban vs Scrum?

Scrum has too many meetings, requires a well groomed backlog, and assumes senior developers so that they can accurately task & plan their stories.

Junior to Mid-Level Team

Given I was running my mid-level team in an Enterprise setting, I knew others would be more than happy to sabotage our teams productivity with meetings of their own. Part of the solution, not part of the problem. New team members, both onshore and offshore, who I expected to be reasonably cross functional whether they liked it or not, needed all the time they could to focus and learn quickly.

No Solid Requirements

Given staffing was changing bi-weekly with an my on-going effort to teach the Subject Matter Experts (SME’s) turned Business Analysts (BA’s) how to create properly groomed stories, there wasn’t anything the team could commit to within a reasonable timeframe. For example, it took us 8 workshops over 3 weeks to get to a solid understanding of what we thought we were building.

No CICD

We also had no build nor DevOps in place to facilitate Continuous Integration and Continuous Delivery. Thus we had no ability for weeks to deliver a working, high quality feature because there was no build to allow Developers & Quality Assurance to verify quality, nor server to deploy it to.

No Roles, Just Fullstack / Cross Functional

Having a Product Owner assumes you have someone either in Business, or who represents them, that knows what to build. The client asked us to use our expertise to help them out in true Consulting style. Thus there was no Product Owner.

There was no need for a Scrum Master. Sprint Planning was pointless because we couldn’t plan 1 to 2 weeks in advanced since high level Epic’s were still being both defined, priced, and architecturally validated. For months. I already knew what the team was working on, and so did they, by their small Trello cards. If people had blockers, they asked me or the team over Slack and we collectively resolved it. There was no need for Retrospectives because there were no Sprints since things changed daily so you couldn’t effectively reflect on what happened the past week because it was ever changing. There were no roles beyond everyone coding the client, server, and some of the DevOps together.

Scrum would of been lot of ceremony with no value.

Enter Kanban

What Kanban does well is allow you to change quickly, allow the team to be productive despite the chaos, with a continuous flow of delivering working software that’s in sharp contrast to the insanity outside their productive world. Unlike Scrum, you much more quickly visualize the work going on “today” and identify problems sooner than later. Since the work in progress tends to be smaller, you can flush out bottlenecks in the process sooner. You can create swimlanes and also identify which ones have bottlenecks.

Flexible to Ever Changing Direction

As each new day brought in new or modified requirements, role changes, and improved DevOps and API offerings, I would change the Backlog to match “today”. Given we had no build, nor DevOps starting from scratch, I had a lot of flexibility to inject more build specific tasks so as to keep away from Yagni until we got a solid enough user story. “No user stories, nor API? No problem, get Mocha working with our Node code.” I’d attempt to stay 1 to 4 days ahead of my team. This was to ensure they were working on what I knew at the time to be real and providing client & user value.

Productive Despite Chaos

Politically, it helped ensure we were being productive and thus visually showing we’re using the client’s money effectively with the fast ability to change course if they wanted something changed faster than a Scrum Sprint would typically allow. This happened often.

Learning the Team’s Strengths, Weaknesses, and Desires

I had a new, junior to mid-level Development team and QA team, on a greenfield client (meaning no existing infrastructure or code), with ever changing requirements, staffing, and contract lengths. Since the team was new and learning the entire Software Development Lifecycle whilst me doing my best to shield them from politics, lack of a CICD process, lack of requirements, and nothing pre-built for them via Yeoman generators / starter projects… I knew things would be slow and unpredictable at first.

What I didn’t know was the team. I didn’t know their strengths, weaknesses, and most importantly, desires. Happy developers are productive developers. A lot of people say they are fullstack to ensure they are employable or because they are insecure that their speciality skill set cannot stand on it’s own. That or they like working in smaller, more cross functional groups.

As much as I expected the team to touch all parts of the development stack, including myself, you always have people who naturally gravitate somewhere, or like to be pushed to a particular area like API’s, services, components, or build level tasks. This should be encouraged just as much as being cross functional to get the most out of them, and the team. Additionally, as the project matures, you have less of a need to be cross functional as often, and tend to see people dive deep over time.

Creating Tasks in Trello

I also didn’t know the team’s ability to estimate their own tasks. It didn’t matter since the user stories weren’t defined enough for them to do so. Thus, I broke all tasks down for the team and included additional DevOps and QA tasks as well into small units. We used Trello, a real-time collaborative project board full of cards, to keep track of the work.

We had 6 columns in our Trello board, from left to right:

1. Bulletin Board: All the documents & images for our project
2. Undefined: Stories & Tasks I didn’t have enough clarity on for the team to work on.
3. Defined: Tasks I fleshed out enough to ensure anyone on the team could work on with clearly defined success criteria, easily merged into a Github Pull Request, and colored with the swimlane it belonged to: Testing, Client UI, Node API, DevOps, and UX.
4. Working On It: What tasks were being actively worked on in the team. I ensured only 1 card per developer
5. Done: For tasks that were done and developer tested, but not QA approved via them manually testing the Card’s associated PR.
6. Approved: QA approved PR’s that merged into the dev branch and deployed via Jenkins Docker build.

Observe the Flow of Development…

What happened next sold me on one of the key strengths of Kanban.

Every day I could immediately see problems. Instantly. It happened just like Andrea Ross said it would, and I’d see where bottlenecks were in the process. Each column in Trello would suddenly get overflowed with cards. You could be near blind, simply squint at the board so you couldn’t actually read anything and STILL SEE IT. The size of the columns told all: you have a bottleneck somewhere here.

It’s called Cycle Time: how long a piece of work goes from left to right. You want to ensure once cards are created, they speed from Undefined to Accepted (left to right, start to finish) as quickly as possible. Typically that process isn’t linear; SOMEWHERE in the journey there is always a bottleneck.

… Adjust as Necessary

How do I know I’m done?

The first one was the success criteria I gave wasn’t clear enough. 90% of my created cards in Defined were moved back to Undefined by the team. Once I gave better success criteria, the development team started to chew through them. I wouldn’t hear from them for hours, then cards would suddenly start piling up in the Done column w/PR’s to boot.

What does the UI look like?

The second one was lack of good wireframes and designs to illustrate both the layout and interactions of how the UI worked. We didn’t yet have budget for a UX resource, so I spent the time myself building low fidelity wireframes that were as accurate as possible and then creating design comps matching our Material Design style guide. I ensured all new cards had relevant design artifacts attached. If the wireframe/design comp changed, I’d move the card from Defined back to Undefined to ensure the team didn’t touch it. If it was too late, I’d create an iteration card to modify an existing piece of work with the updated UI/functionality change.

How do I test it works?

The third one was the inability for QA to test functionality as cards started piling up in the Done column. QA didn’t yet have the build running locally, nor a QA environment to test on, nor a set of tools to help them automate it, nor a lead to help mentor them towards this.

So I picked up the torch, implemented Angular’s Protractor with the Cucumber version, then had a team member get an actual working feature through Gulp. I then worked with the QA team and BA’s to help define better Cucumber features through workshops so they were easier to test. I attached these as additional artifacts to each card where applicable.

Finally, we started Dockerizing our build to use through Kitematic & DockerHub. Given how hard it was to get Redis + Node working the same between the Developer’s Macs and the QA’s Windows machines with various lack of admin rights, this helped ensure things actually worked, quickly, without debugging install or configuration issues.

Continually Improve

This process never stopped. Sometimes it was small bottlenecks or even just blockers and we’d do our best to improve the process. Despite the politics, climate of unknowing, and constant readjustment of requirements & processes… it felt good to be making both progress and improving the process.

Developers got to zone out by donning headphones to jam on code all day. Working code continually emerged as long as I fed this process.

We almost got to the point where the developers had no clue about the ever changing conditions on the ground with the client, ignored it when I brought it up, and focused strictly on questions about specific tasks. I’d call that a process win.

Challenges

It wasn’t all rose colored glasses.

The Importance of Good, Upfront DevOps

The main pain point throughout the entire process was our DevOps starting late in the cycle. Without a good CICD process, Scrum and Kanban don’t really seem to work all that well in tracking “actual work” because no actual work… works. Now, the CI portion we knocked out of the park ourselves and quickly while waiting for confirmed requirements using Github and Jenkins in Docker + AWS. Mostly. The CD, however, took awhile.

What we wanted at first was once a PR was approved, the code would, after a successful Jenkins build, deploy a Docker container of our code to a publicly accessible Amazon Web Service (AWS) instance. It took us about 3 months to get that going given our resource constraints & timing. In the interim, we did a lot of mocks and testing on localhost with ngrok for demos.

Once our Docker deployment was working we started having code be deployed without our knowledge in a good way; the development team just focused on completing cards, and eventually the QA would focus on verifying manually what made it through the automated QA process to the server matched up.

The latter took forever simply because I was stretched too thin running the Development team, helping the DevOps team, doing my own wireframes and design comps, mentoring the BA’s to write awesome user stories via Behavioral Driven Development to minimize our story grooming sessions, and keeping Senior Management in the loop.

Even with Analysts starting the DevOps, it’s clear having them full time on that endeavor payed off big time. In the future, I’m curious if I’d rather focus on that full time myself since it seems to have the largest, cross team impact regardless of whether the requirements, UX, and CI are in a good or bad spot.

Wireframing & Designing at the Same Time vs. Staggered

While me being the same person to do the wireframes made it easier to build design comps around them, it simnifically reduced the time I could spend with other teams. When the Undefined column would get too full, I’d have to spend the early part of the week ensuring I had enough information to wireframe. I’d then spend the weekend on the design comps and then break them down into easily tackled, small PR tasks in Trello. This wasn’t sustainable and I knew it, but was banking on getting budget for UX resources.

While I was helping the BA’s, Development Team, and QA by ensuring the stories had a visual component to help ensure we’re all on the same page of what the user story looked like, I’d end up neglecting other things like refining those very stories, not unblocking the development team when they’d get stuck on build or architecture issues, nor helping push the DevOps team to help the QA do their job.

Rather than complain, I made a daily tactical call on what to focus on based on what Trello was telling me. Once we got the UX resource onboard, he worked aside the BA’s and that helped a ton; at that point I could just match the design comps to his wireframes, cutting my work in half + his were of insanely higher quality for talent & focus reasons.

What this tells me is that unless I have a huge backlog of build and DevOps work in the pipeline, I’ll be hard pressed in the future to keep my development team busy with those tasks for a long time without quickly needing a proper UX team member(s).

QA in Lean Engineering

I didn’t have enough seniors to delegate management tasks to, and coupled with my CD problems, I struggled to keep QA productive. While our developers were using linting compilers, complexity metrics, unit and integration testing with end to end testing, no one was laser focused on improving the latter part of the QA CD pipeline. I’d made some headway in getting QA involved in the beginning to help contribute to ensuring good user stories came out of our workshops. Where I struggled was giving them enough of my time to teach them basic JavaScript coding, DevOps, and helping them walk through their testing plans on what we did have to start to develop a cadence.

A lot of this was we just didn’t have that much to test yet and the other was… well, nothing. I did the best I could working insane hours. If I were to do it again, I’d assign a senior dev interested in furthering their testing & DevOps chops to work with them on owning the CD process, and ensuring a good quality pipeline.

In Lean Engineering, QA is no longer thrown code to test weeks or months later. Instead, they are brought into the beginning of the process and the end to improve the entire pipeline. You can’t do that if you don’t have a DevOps pipeline.

User Feedback

The same problem I had with QA I had with user feedback. Part of Lean engineering with Kanban is continuously improve not just the process, but the software. You do this by giving the working build to a user, testing it, and taking their feedback BACK into the process. While doing wireframes, I did informal and adhoc user interviews, created basic Persona’s to differentiate who we were targeting, but did not get to validate this with released software until late in the cycle.

This actually wasn’t much of a bad thing, but rather, a challenge because a working build didn’t emerge until much later in the cycle, so we just did localhost demo’s & testing vs. “use whatever device you have on your person or will use in your job”. I had already had extensive, informal discussions with the target users and really liked them as people. It just came up when I’d look at swimlanes via colors in Trello cards, the features had a huge cycle time in knowing if they were valid or not from user testing.

Role Changes

Traditionally in Agile, I’ve found I do most of my management efforts on Sprint Planning and post Retrospective. I ensure the requirements are rock solid and follow up on loose ends, and take action items seriously during retrospectives where new things need to be implemented or changed. The rest of the time I architect, pair program, and code.

In Kanban, it was very different. My role, daily, was to manage away problems for the team. Instead of a weekly or bi-weekly discovery, this was daily to hourly. I’d adjust based on what Trello was telling me. It gave me a greater insight into how my management efforts positively and negatively affected the team.

I also liked continually working with the team to improve our process. I’ve done that before in teams with Scrum, but process improvement usually fell behind “getting my story done” in terms of priority. In Kanban, fixing the bottleneck and improving the process is the priority.

I’ve found I really like Kanban. The consulting world is full of extremely hard software problems surrounded by politics and chaos. I love those aspects and Kanban is now my tool of choice for managing teams within it.

Citations

I wanted to thank Joel Hooks for telling me about Kanban being an alternative to Scrum years ago. If Joel likes something, I typically trust his judgement that it must be good.

Also thanks to my manager, Matt Lancaster, for teaching me about Lean engineering processes. You can see him speak about the process below.

Thanks to Eric Motazedi for teaching me about BDD and why workshops are so important.

Finally thanks to the Richmond Capital Kanban group for teaching me more about how Kanban works.

Introduction: Why Unit Test?

Lua in Corona SDK has 3 issues when your game/application code base grows to any large size.

First, Lua is a dynamic language much like JavaScript, Ruby, and Python. As such, you have little to no help from the compiler to ensure your code expects even basic parameters being passed to your functions as well as misspellings.

Secondly, Lua is dynamic at runtime. You actually need to run the code to see how it actually works. Examples include combining strings together to dynamically access properties on dynamically created objects in an asynchronous way.

Third, even if encapsulated, you have no way of knowing if your new code breaks existing code, or if modifying existing code allows it to work the same way with some assurance. This problem is not unique to Lua, it’s unique to any complex code base regardless of language.

All 3 combined necessitate a need for unit tests. Some would argue even just 1 of the above.

Anatomy of Unit Testing

Unit testing, as far as we’re concerned with Lua, are a bunch of functions that make sure things work as expected. Inside of those functions, you write those expectations about how you expect things to work as a bunch of assert functions. These groups of functions aren’t actually part of your main code base; they’re grouped together in a test folder and called a test suite. The more of them you have, the more test coverage you have.

TDD or Test Driven Development is where you actually write the above paragraph test code first, and THEN actually write the code it’s testing afterwards. You start with writing a test that fails, you write the code to make it pass, and then ensure the test passes. Then you repeat.

The above 2 paragraphs can, and do fill books with the details of TDD & unit testing… but that’s all you need to know for now. Heck, you can ignore everything I write here, start to proactively use assert, and your coding life will improve a lot.

Asserts
Let’s start at the beginning. Lua already has an expectation function, called “assert”. It looks like this:

local wubWubWub = true
assert(wubWubWub, "Someone forgot to drop the bass.")

This code asserts or “states positively” that the variable is true. If it were false, an error would be thrown with that string “Someone forgot to drop the bass.” passed into the error function. If you’re not aware, the error function in Lua stops execution of the current script and prints whatever string it has to the console/terminal. Secondly, all functions in Lua are implied to be successful if they return true.

Even without unit testing, using assert, you can be proactive in finding errors. For example, I use it all the time in manual getter/setters in Lua (not metatable ones, the set/get + method name convention). Since Lua has no typing system, I ensure my inputs are sanitized like so:

function setSpeed(newValue)
   assert(newValue ~= nil, "You cannot set speed to nil.")
   assert(type(newValue) == "number", "You must set speed to a number value.")
   self.speed = newValue
end

Those 2 functions alone find ALL kinds of silly bugs where someone, somewhere accidentally set a value to nil and it made it’s way deep into the bowels of some class, and I’m wondering who’s fault it is. When everyone starts doing this, it makes it really easy to find who caused the bug, and quickly.

Yes, there is a performance cost to assert. However, it’s easier to remove a bunch of assert functions scattered everywhere via a Find / Replace from solid code then it is at add them to code that runs very fast with lots of unknown bugs.

Moar Asserts

Just about every testing framework expands upon the above function. In fact, 80% of what they offer in their libraries and frameworks are additional assert functions. Why? Three reasons. First, would you rather write this?

local icon = display.newImage("icon.png")
assert(icon ~= nil, "Icon image cannot be found.")

or this:

local icon = display.newImage("icon.png")
assert_not_nil(icon, "Icon image cannot be found.")

The second reason is it’s more clear what that is testing; the function name alone tells you what you need to know before you’ve even made it to the parameters.

Here’s another example:

local currentSpeed = character.speed
character:setSpeed(currentSpeed + 1)
assert(character.speed > currentSpeed, "Character speed did not increase.")

vs writing:

local currentSpeed = character.speed
character:setSpeed(currentSpeed + 1)
assert_gt(character.speed, currentSpeed, "Character speed did not increase.")

Now this one may appear backwards; “A comma vs. using the normal mathematical construct!?”

Keep in mind, however, many bugs are caused by misplaced operators. For example, developers often will use = instead of == to assign a value, or they’ll use > vs. >= for edge cases, etc. In writing that code, it’s completely legal, and Lua’s interpreter won’t give you an error when you run it. Using assert_gt in this instance will ensure your expected value is there, as well as ensure you’ve use the operator correctly. If not, it’ll actually… you know… help you out!

And although I bash Lua for not having a type system, it does have a type function for a reason. You can test a variety of types such as assert_not_boolean for a return value that’s supposed to be a number, and assert_metatable if you’re doing funky metatable magic.

Suites

A suite is just a series of functions that are related. For example, in my example video I show my file suite which has unit tests for testing my DeleteFileService class and my ReadFileContentsService class. Since reading and writing and deleting files are something I consider related, I created a file suite, or “a bunch of functions that test file shiz”.

While lunatest can test functions inline, as an OOP guy, to me that’s just gross. I like the more organized suites where all the functions are in their own file. Lua calls it a file, I call it a Class, Lunatest calls it a suite… we’re all happy.

Here’s my file one:

module(..., package.seeall)

function test_saveFile()
	require "com.jxl.core.services.ReadFileContentsService"

	local saveFile = SaveFileService:new()
	local data = "moo"
	assert_true(saveFile:saveFile("test.txt", system.DocumentsDirectory, data), "Failed to save test.txt")
end

function test_readFile()
	require "com.jxl.core.services.ReadFileContentsService"
	require "com.jxl.core.services.SaveFileService"

	local saveFile = SaveFileService:new()
	local data = "moo"
	assert_true(saveFile:saveFile("test.txt", system.DocumentsDirectory, data), "Failed to save test.txt for use in reading.")

	local readFile = ReadFileContentsService:new()
	local contents = readFile:readFileContents("test.txt", system.DocumentsDirectory)
	assert_string(contents, "contents are not a string.")
	assert_equal(contents, data, "Data written to file does not match what we just read out of it.")
end

2 things to note about this file. First, I use the much loathed module(…, package.seeall) at the top. This is what lunatest wants in how it loads modules so… you’ll need to do this too (yes, I temporarily hacked lunatest to support Corona’s packages, but it wasn’t worth it).

Second, notice the 2 functions are both global and start with “test_”. Any function you want Lunatest to run as a test, you need to prefix it with “test_” in the function name. Notice they aren’t prefixed with local, they’re simple global functions.

That’s it. Put a bunch of functions in that file, make an assert or two within them, save it, and then in your main file, tell luna test about it.

Advanced Suites

The above is good enough for writing suites that’ll help you. Here’s 4 more cool things suites can do.

If you have repetitive code that needs to be run before every test, you can run it in the test setup. This ensures you only have to run it once, you have the option of aborting the test, and it’s run in a protected manner (aka pcall). Additionally, you don’t have to call this yourself, nor remember to do so, Lunatest does this for you. In my StateMachineSuite, I have to instantiate the StateMachine class for every call so I put it in setup.

If you have code that needs to be cleaned up a lot or in a particular order, you can utilize the teardown. If you implement one, it’s called after every single test case. This also ensures that if everything is deleted, strange memory bugs are more easily found. Some classes require more than just nilling out their variables, in the case of Corona SDK Display Objects and Widgets which must have their removeSelf called, THEN you can nil out the variable reference. You can also ensure all of the benefits of setup, just in a function called teardown where you clean up your mess.

Finally, there is a suite_setup and a suite_teardown. Unlike setup and teardown, these are only called once for the entire suite; suite_setup before any tests are run, and suite_teardown after everything, including the last teardown, is called. Sometimes you don’t need unique setup code for your tests so you can put it here instead. This is also a good place for class imports.

Here’s my StateMachine example. Notice it has a suite_setup (but no suite_teardown). The setup instantiates the StateMachine and the teardown ensures it’s deleted so each test function gets a brand new SuiteMachine instance.

module(..., package.seeall)

function suite_setup()
	require "com.jxl.core.statemachine.State"
	require "com.jxl.core.statemachine.StateMachine"
	require "com.jxl.core.statemachine.BaseState"
end

function setup()
	machine = StateMachine:new()
end

function teardown()
	machine = nil
end

function test_classWorks()
	assert_not_nil(machine)
end

function test_verifyInitialStateIsNil()
	assert_nil(machine.state)
end

function test_verifyInitialStateIsNullWithStates()
	local initial = "playing"
	machine:addState(initial)
	machine:addState("stopped")
	assert_nil(machine.state)
end

function test_verifyInitialStateIsNotNil()
	local initial = "playing"
	machine:addState(initial)
	machine:addState("stopped")
	machine:setInitialState(initial)
	assert_equal(initial, machine.state)
end

function test_enter()
	local t = {}
	local hitCallback = false
	function t.onPlayingEnter(event)
		assert_equal(event.toState, "playing")
		assert_equal(event.fromState, "idle")
		hitCallback = true
	end
	machine:addState("idle")
	machine:addState("playing", { enter = t.onPlayingEnter, from="*"})
	machine:setInitialState("idle")
	assert_true(machine:canChangeStateTo("playing"), "Not alowed to change to state playing.")
	assert_true(machine:changeState("playing"))
	assert_equal("playing", machine.state)
	assert_true(hitCallback, "Didn't hit the onPlayingEnter callback.")
end

function test_preventInitialOnEnterEvent()
	local t = {}
	local hitCallback = false
	function t.onPlayingEnter(event)
		hitCallback = true
	end
	machine:addState("idle")
	machine:addState("playing", { enter = t.onPlayingEnter, from="*"})
	machine:setInitialState("idle")
	assert_false(hitCallback, "Hit the callback when I had no initial state set.")
end

function test_exit()
	local t = {}
	local hitCallback = false
	function t.onPlayingExit(event)
		hitCallback = true
	end
	machine:addState("idle", {exit = t.onPlayingExit})
	machine:addState("playing", {from="*"})
	machine:setInitialState("idle")
	machine:changeState("playing")
	assert_true(hitCallback, "Never called onPlayingExit.")
end

function test_ensurePathAcceptable()
	machine:addState("prone")
	machine:addState("standing", {from="*"})
	machine:addState("running", {from={"standing"}})
	machine:setInitialState("standing")
	assert_true(machine:changeState("running"), "Failed to ensure correct path.")
end

function test_ensurePathUnacceptable()
	machine:addState("prone")
	machine:addState("standing", {from="*"})
	machine:addState("running", {from={"standing"}})
	machine:setInitialState("prone")
	assert_false(machine:changeState("running"), "Failed to ensure correct path.")
end

function test_hierarchical()
	local t = {}
	local calledonAttack = false
	local calledOnMeleeAttack = false
	function t.onAttack(event)
		calledonAttack = true
	end

	function t.onMeleeAttack(event)
		calledOnMeleeAttack = true
	end

	machine:addState("idle", {from="*"})
	machine:addState("attack",{from = "idle", enter = t.onAttack})
	machine:addState("melee attack", {parent = "attack", from = "attack", enter = t.onMeleeAttack})
	machine:addState("smash",{parent = "melee attack", enter = t.onSmash})
	machine:addState("missle attack",{parent = "attack", enter = onMissle})

	machine:setInitialState("idle")

	assert_true(machine:canChangeStateTo("attack"), "Cannot change to state attack from idle!?")
	assert_false(machine:canChangeStateTo("melee attack"), "Somehow we're allowed to change to melee attack even though we're not in the attack base state.")
	assert_false(machine:changeState("melee attack"), "We're somehow allowed to bypass the attack state and go straigt into the melee attack state.")
	assert_true(machine:changeState("attack"), "We're not allowed to go to the attack state from the idle state?")
	assert_false(machine:canChangeStateTo("attack"), "We're allowed to change to a state we're already in?")
	assert_true(machine:canChangeStateTo("melee attack"), "We're not allowed to go to our child state melee attack from attack?")
	assert_true(machine:changeState("melee attack"), "I don't get it, we're in the parent attack state, why can't we change?")
	assert_true(machine:canChangeStateTo("smash"), "We're not allowed to go to our smash child state from our parent melee attack state?")
	
	assert_true(machine:canChangeStateTo("attack"), "We're not allowed to go back to our parent attack state?")
	assert_true(machine:changeState("smash"), "We're not allowed to actually change state to our smash child state.")
	assert_false(machine:changeState("attack"))
	assert_true(machine:changeState("melee attack"))
	assert_true(machine:canChangeStateTo("attack"))
	assert_true(machine:canChangeStateTo("smash"))
	assert_true(machine:changeState("attack"))
end

Pay attention to that last part, it has some good and bad practices. The whole point of unit tests is to test 1 thing or unit. You shouldn’t have 50 billion asserts like I do. Worse, you’ll notice some of the asserts at the bottom do not have custom error messages in the 3rd parameter. If any 1 of those fail, there is no way to tell which one failed. Bad, Jesse, BAD!

Run

Setting up all of the above is a snap. Ready?

In your main.lua file, import Lunatest:

require "lunatest"

Next, add your suites:

lunatest.suite("tests.com.jxl.core.ServicesSuite")
lunatest.suite("tests.com.jxl.core.services.ReadFileContentsServiceSuite")
lunatest.suite("tests.com.jxl.core.statemachine.StateMachineSuite")
lunatest.suite("tests.com.jxl.zombiestick.services.LoadLevelServiceTest")

Finally, call run:

lunatest.run()

That’s it! You’ll see the report of stuff in the console/terminal.

Conclusions

The problem with unit testing is that you need to have units to actually test. A lot of code that wasn’t written to be unit tested needs to be refactored first which can be a lot of work. If it’s also entangled with other code that’s also not easily testable… you see where this is going. That’s ok. You can start in one section, or test high level results. Yes, your setup code may be burdensome, but it’s something. Automated tests, even if a certain section, can help you a lot. Additionally, when writing new code, think about writing it in a way that’s testable, even if you never actually test it. This often results in less coupled code anyway.

Additionally, while testing is in fact creating more code, you find more bugs, early, and faster, proactively. For games that require quick iterations… this can be tricky. If the game needs to be built to verify it’s even fun, is it worth it to unit test? As you make a lot of games in the same tech (whether Lua, C#, ActionScript, Java, whatever…), you’ll start to gather are a large set of functions, libraries, and classes that are reusable from project to project. THOSE are worth unit testing.

Unit tests are just a bunch of functions that test expectations, and are organized in suites. You run a bunch of test suites inside of Lunatest. Unit tests help ensure your function types are correct since Lua has no helpful compiler to help on this front as well as spelling mistakes. It also verifies your code works as you expect at runtime. Finally, for larger code bases, you can add new code without worry of breaking old code, including if you modify old code. The more unit tests you write, the more coverage you have. The more coverage, the easier it is to manage a larger code base.

Remember, unit tests are code too. You can still follow all the best practices your used to such as OOP, DRY, and being clean. MOAR UNIT TESTS!

Title image “Moon” by S4cr4m3nt.

Also posted on iOS Gaming.