We were suffering from slow integration tests on our server when I discovered something that sped up performance by 15 times!



# TLDR;

Set `fsync=off` in your postgres config.

# The Problem

For our game [BattleTabs](http://battletabs.com/) run a custom sockets based API server. To ensure that the server is working as intended I like to write integration tests that hit the database. This gives a good level of confidence that calling that endpoint from the game client is going to work as expected.

The issue is that the tests were taking quite a while to run:

[![](./before.png)](./before.png)

I narrowed the issue down to where most of the time was being spent:

[![](./trunc-before.png)](./trunc-before.png)

We must truncate the database before each test runs so that there is no state from the previous test that can affect the results. The problem is that this truncate seems to be taking an inordinate amount of time.

# The Solution

After some googling I came across [this post](https://dev.to/thejessleigh/speed-up-your-postgresql-unit-tests-with-one-weird-trick-364p#:~:text=fsync,are%20physically%20written%20to%20disk.) which seemed to suggest that there was a magical config value `fsync` that I could disable which would speed things up.

So I set `fsync=false` in my postgres config and restarted my docker container and..

[![](./trunc-after.png)](./trunc-after.png)

Wow! Thats a 15x speedup! Incredible.

So whats the downside? Well `fsync` ensures that changes are written (synced) to disk when Postgres makes a transaction. So by disabling it you are disabling protection from crashes power-cuts and whatnot so its [definitely not recommended in production](https://www.2ndquadrant.com/en/blog/postgresql-fsync-off-warning-in-config-file/) but when running tests we dont really care about data integrity so its safe to disable it.

# Github Actions

I wondered if it was possible to apply this sort of speedup to the CI which runs all the integration tests on each push.

To cut a long story short it appears you [cant supply config params to the standard postgres image while running in Github Actions](https://stackoverflow.com/questions/65438055/how-to-add-config-args-to-postgres-service-container-in-github-action/65444387?noredirect=1#comment115705280_65444387) but fortunately we can use another postgres image from Bitnami which does let us disable fsync.

```yaml
jobs:
  test-and-build-pr:
    runs-on: ubuntu-latest

    services:
      postgres:
        image: "bitnami/postgresql:latest"
        env:
          POSTGRESQL_DATABASE: postgres
          POSTGRESQL_USERNAME: postgres
          POSTGRESQL_PASSWORD: postgres
          POSTGRESQL_FSYNC: "off"
        options: >-
          --health-cmd "pg_isready -d postgres -U postgres -p 5432"
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432
```

The result is a speedup of 3x, not quite as dramatic as the local speedup (probably because im running postgres in a linux docker container on windows locally and Github is running it on linux) but an impressive performance boost nonetheless!

So I promised in my [last post](https://www.mikecann.blog/programming/unity-ash-a-different-way-of-thinking-about-making-games-in-unity/) to show how how [Unity-Ash](https://github.com/mikecann/Unity-Ash) can make things easyier when it comes to Unit Testing.



I have added some tests to the [Unity Asteroids](https://github.com/mikecann/UnityAshteroids) example game. Lets take a look at one of the simpler systems as an example, the DeathThroesSystem:

[code lang="csharp"]
public class DeathThroesSystem : NodelessSystem<DeathThroes, Entity, Audio>
{
public DeathThroesSystem()
{
\_updateCallback = OnUpdate;
\_nodeAddedCallback = OnNodeAdded;
}

    private void OnNodeAdded(DeathThroes death, Entity entity, Audio audio)
    {
        audio.Play(death.deathSound);
    }

    private void OnUpdate(float delta, DeathThroes death, Entity entity, Audio audio)
    {
        death.countdown -= delta;
        if (death.countdown <= 0)
            entity.Destroy();
    }

}
[/code]

We can see its a really simple system that does a couple of things.

First we want to test that when a node is added to the system we play a sound effect. Using Unity-Test tools you can quickly whip up a test case:

[code lang="csharp"][testfixture]
public class DeathThroesSystemTests : UnityUnitTest
{
private IEngine \_engine;
private DeathThroesSystem \_system;

    [SetUp]
    public void Setup()
    {
        _system = new DeathThroesSystem();
        _engine = new Engine();
        _engine.AddSystem(_system, 0);
    }

    [Test]
    public void WhenANodeIsAdded_DeathSoundPlays()
    {
        var e = AddEntityToEngine();

        Assert.AreEqual(1, e.GetComponent<Audio>().toPlay.Count);
        Assert.AreEqual(e.GetComponent<DeathThroes>().deathSound, e.GetComponent<Audio>().toPlay[0]);
    }

    private GameObject AddEntityToEngine()
    {
        var obj = CreateGameObject();
        obj.AddComponent<DeathThroes>();
        obj.AddComponent<Audio>();
        obj.AddComponent<Entity>();
        _engine.AddEntity(obj.AddComponent<Entity>());
        return obj;
    }

}
[/code]

I wrote a little helper that adds an entity to the engine with the necessary components. In the future we could use reflection to looup the types on the Nodeless system, but for now its enough to satisfy the test:

[![2015-11-02_17-28-19](https://www.mikecann.blog/wp-content/uploads/2015/11/2015-11-02_17-28-19.png)](https://www.mikecann.blog/wp-content/uploads/2015/11/2015-11-02_17-28-19.png)

Next we want to check that after update the countdown is decremented.

[code lang="csharp"][test]
public void AfterUpdate_CountdownDecremented()
{
var e = AddEntityToEngine();

    var before = e.GetComponent<DeathThroes>().countdown;

    _engine.Update(1.5f);

    Assert.AreEqual(before - 1.5f, e.GetComponent<DeathThroes>().countdown, 0.01f);

}
[/code]

Easy, now we want to check that when the countdown is less than or equal to zero, the entity is destroyed:

[code lang="csharp"][test]
public void AfterCountdownTimerEnds_EntityDestroyed()
{
var e = AddEntityToEngine();

    var before = e.GetComponent<DeathThroes>().countdown;

    _engine.Update(before + 1);

    Assert.IsTrue(e.GetComponent<Entity>().IsDestroyed);

}
[/code]

Sweet and thats it! Sure we could add a few more tests for some of the corner cases but as an example I think it serves its purpose.

Let me know in the comments or email me: mike.cann@gmail.com with what you think!

For the [past 5 months](https://www.mikecann.blog/uncategorized/started-work-at-thebroth-in-perth/) my day job has been an AS3 developer with the awesome folks over at The Broth in Perth. Having worked with AS3 for most of my professional career it was a good fit for my coding skills.



I hadn't worked in AS3 for about 2 years before joining but there wasn't much to catch up on regarding the language or platform (sadly things arent moving very fast in the Flash world these days) but there was much to catch up with regards to my new interest in Unit Testing and TDD. I made it my mission to become the testing, clean code and best practices guy here and as such have been learning and writing many tests.

As anyone that has done unit testing will know, mocking is a big part of unit testing. In AS3 one of the main mocking libraries is called [Mockolate](https://mockolate.org/). Its an excellent library but unfortunately it hasnt been updated for over 3 years, so when I ran into an issue with it in conjunction with another AS3 library [promise-as3](https://github.com/CodeCatalyst/promise-as3) (not updated for 1+ years) it lead to weeks of frustration.

The issue, as documented on their issue tracker [here](https://github.com/CodeCatalyst/promise-as3/issues/27), is that when you try to use a Promise as return of a function call then it results in strange errors:

[code lang="csharp"]
D:\libs\adobe\flex\sdk\4.6\bin\adl.exe -profile extendedDesktop D:\testApp\out\test\desktop_flexunit-descriptor.xml D:\testApp\out\test\desktop
Player connected; session starting.
[Fault] exception, information=VerifyError: Error #1053: Illegal override of TestInterface600C55060B003CF6CD88EB5CFE69DFE741318F03 in mockolate.generated.TestInterface600C55060B003CF6CD88EB5CFE69DFE741318F03
[/code]

The same goes for if you try to use Promises in interfaces.

Well after many hours of trail and error I found the problem. It looks as if there was a circular dependency within the Promises library so within the constructor of the Promise and Resolver classes depended upon each other. This meant that Mockolates subsystem (Floxy) couldnt generate proxy classes for them and thus they couldnt be mocked.

I fixed the issue, forked and committed:

[https://github.com/mikecann/promise-as3](https://github.com/mikecann/promise-as3)

I also submitted a pull request here:

[https://github.com/CodeCatalyst/promise-as3/pull/49](https://github.com/CodeCatalyst/promise-as3/pull/49)

But I don't have much hope that it will ever get accepted due to the dead nature of the library (and the ecosystem as a whole) but I hope it helps any other lost AS3 sheep in the future!

> This is part of a three-post series on working with Parse.com in Unity. For more info please see the other posts in the series:
>
> [Part 1 - Intro and App Structure](https://www.mikecann.blog/programming/working-with-parse-com-in-unity-3d-part-1-intro-and-app-structure/)
>
> [Part 2 - Services, Helpers and Looming](https://www.mikecann.blog/programming/working-with-parse-com-in-unity-part-2-services-helpers-and-looming/)
>
> Part 3 - Tests, Typescript and Common Code



In the last post I covered how to use Parse.com in Unity itself, in this post I want to talk about to to go about writing backend code.

**Note all the code talked about can be found in the [Parse Unity Sample Project on Github.](https://github.com/mikecann/ParseUnitySampleProject)**

## Environment

I briefly talked about App structure in [my first post](https://www.mikecann.blog/?p=5435). I like to use use Visual Studio with Typescript and C# for my Backend as they all play nicely together an produce a hassle free way of coding up the backend.

I like to have the Parse command line app running in develop mode (parse develop "Parse Unity Sample") at the same time so I can see whats happening on the server when I call it, and it allows for very quick iterations:

[![2014-11-11_08-39-16](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-39-16-1024x268.png)](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-39-16.png)

## Typescript

I have talked a lot in the past about my love for Typescript and so I love to use it whenever I can. Parse lets you run Javascript code on the server so I use Typescript that compiles to Javascript. To get it to work I first create a Typescript project that has been setup with CommonJS as the module system:

[![2014-11-11_08-40-46](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-40-46.png)](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-40-46.png)

I then make sure all the code is contained withing the /cloud folder (so that the require() works):

[![2014-11-11_08-45-22](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-45-22-1024x324.png)](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-45-22.png)

It works well, particularly when combined with my (not yet finished) Typescript definition for Parse which provides type safety for as much as possible:

[![2014-11-11_08-47-02](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-47-02.png)](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-47-02.png)

For example, the code that is run before a User is saved looks like:

[code lang="AS3"]
// Force this TS file to become a module
export var x = 2;

Parse.Cloud.beforeSave("\_User", (request, response) => {

    // Must have a player name
    if (request.object.get("playerName") == null || request.object.get("playerName") == "")
        return response.error("Must supply a player name when creating a new user");

    // Email and username must equal
    if (request.object.get("email") != request.object.get("username"))
        return response.error("Username and email address must be equal");

    // All done
    response.success();

});
[/code]

## Testing

Because there is no way to run Parse cloud code offline, all tests must run on code that runs on the Parse servers. At first this sounded really nasty to me and almost put me off using Parse all together but once I realised that I could just create another App for testing and structure my test in such a way that I could isolate each test, I grew to like it, I actually really enjoy writing these tests now.

I like to use NUnit with the Parse .NET SDK for the testing because it lets us use some more advanced C# features such as async / await which the Unity SDK hasn't got access too, and more importantly it returns the server error messages (unlike Unity) which we can test against.

To get started just create a Test class in your Typescript project (surprisingly Typescript projects work well C# within them in Visual Studio) and start testing:

[code lang="csharp"]
namespace ParseUnitySampleBackend.Tests
{
[TestFixture]
public class SaveUserTests
{
[SetUp]
public async void Init()
{
TestingHelpers.InitParse();
ParseUser.LogOut();
}

        [Test]
        [ExpectedException(ExpectedMessage = "Must supply a player name when creating a new user")]
        public async void RequiresPlayerName()
        {
            var user = new GameUser()
            {
                Username = TestingHelpers.GetRandomUserEmail(),
                Password = "a"
            };
            await user.SignUpAsync();
        }

    ...

[/code]

I included some simple helpers that I like to use for testing which setup Parse before each test.

If you use Visual Studio's Test Explorer with the parse command line you can get really good feedback on what is happening on the server:

[![2014-11-11_08-59-15](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-59-15-1024x386.png)](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_08-59-15.png)

## Common Code

Because I write my tests in C# and my Unity code is in C# I would like to share my common code between the two projects. Unfortunately simply splitting the project out into a library project then including it as a reference in the testing project doesn't work because Unity requires a different compiler (Unity 3.5 subset on mono) and thus when you try to add that as a reference you get errors related to invalid assemblies:

[![2014-11-11_09-03-05](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_09-03-05.png)](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_09-03-05.png)

The solution I found is to use a little known trick of linking source. To do this select the "Models" folder from the common project and while holding Control and Shift drag it into the Backend project, you should note that the cursor changes to a little shortcut icon and when in the backend project the file icons now have a shortcut icon to indicate they are linked:

[![2014-11-11_09-05-26](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_09-05-26.png)](https://www.mikecann.blog/wp-content/uploads/2014/11/2014-11-11_09-05-26.png)

This means that files are linked to the Common project so they are included in compilation and any changes you make to those files in either the Common project or Backend project will be reflected in the other.

This is perfect as it now lets us compile the same files using a different compiler and version of Parse.

## Conclusion

Well thats it for my three part post on how to get started using Parse in Unity. I hope it helps some people, please do leave me a comment or email me: mike.cann@gmail.com if you have any questions.

Happy coding!

[![](/wp-content/uploads/2011/10/2011-10-09_1257.png "2011-10-09_1257")](/wp-content/uploads/2011/10/2011-10-09_1257.png)

The second day of [try{harder}](/posts/try-harder-my-haxe-slides-and-code/) was dedicated to a single topic; test driven development (TDD).



The group was split into pairs and given the task of using TDD to write a solver for the game of life in AS3\. After an hour we then threw away everything we had done, swapped partners and repeated the process.

This was extremely valuable for me as I had never written a unit test before. Seeing how different people tackled the same problem was fascinating and informative.

After repeating the process three times Stray asked if I was interested in teaming up with another attendee of the conference [Alec McEachran](https://www.google.co.uk/url?sa=t&source=web&cd=1&sqi=2&ved=0CBsQFjAA&url=http%3A%2F%2Falecmce.com%2F&ei=jZyRTp-fEcmAhQeIwtn0Dw&usg=AFQjCNEKPdue-giHnTp0HZCJwVWz3QeVoQ) to investigate unit testing in haXe. It was a great idea as it meant we both could investigate how unit testing worked in haXe and it would give me another code example for my talk the following day.

After a brief search we decided on Mike Stead's [MassiveUnit](https://github.com/massiveinteractive/MassiveUnit) for testing as the testing syntax looked similar to FlexUnit and it contained a toolchain for running the tests on multiple platforms.

An example of a test we wrote is:

```haxe
package ;
import massive.munit.Assert;
import Grid;

/**
 * ...
 * @author MikeC &amp; Alec McEachran
 */

class GridTest
{
	public var grid : Grid;

	@Before
	public function before():Void
	{
		grid = new Grid(3, 3);
	}

	@After
	public function after():Void
	{
		grid = null;
	}

	@Test
	public function initiallyThereAreNoLiveNeighbors():Void
	{
		var liveNeighbors = grid.getLiveNeighbors(1, 1);
		Assert.isTrue(liveNeighbors == 0);
	}

	@Test
	public function liveNeighborCountIsAccurate():Void
	{
		grid.set(0, 0, true);
		grid.set(1, 0, true);
		grid.set(2, 1, true);

		var liveNeighbors = grid.getLiveNeighbors(1, 1);
		Assert.isTrue(liveNeighbors == 3);
	}

}

```

It should look fairly familiar to anyone who has used FlexUnit before. The metatags @Before @After and @Test perform in exactly the same way as they do in FlexUnit. Another benefit of using munit over the built in testing framework in haXe is that you are given a tool to run tests on all platforms simultaneously:

```haxe
haxelib run munit test test.hxml

```

When executed you get something that looks like the following:

[![](/wp-content/uploads/2011/10/ScreenHunter_01-Oct.-09-13.54.jpg "ScreenHunter_01 Oct. 09 13.54")](/wp-content/uploads/2011/10/ScreenHunter_01-Oct.-09-13.54.jpg)

Which presents a nice graphical representation of the tests run and which failed (if any).

Once built and tested we decided to give the code a simple visual representation. We wanted to show off the ability for haXe to target multiple platforms. To do this we decided to go with [NME ](https://www.haxenme.org/)which I had been experimenting around with recently.

[NME ](https://www.haxenme.org/)is a library and tool chain for haXe designed to allow the developer to use the flash API on multiple platforms. They achieve this by writing platform targeted version of the flash API. So what this means is code such as the following:

```haxe

package ;
import flash.display.Bitmap;
import flash.display.BitmapData;
import flash.display.MovieClip;
import flash.geom.Rectangle;

/**
 * ...
 * @author MikeC &amp; Alec McEachran
 */

class Render
{

	private var _cellSize : Int;
	private var _renderTarget : BitmapData;
	private var _rect:Rectangle;

	public function new(container:MovieClip, cols:Int, rows:Int, cellSize:Int)
	{
		_cellSize = cellSize;
		_renderTarget = new BitmapData(cols * cellSize, rows * cellSize, false);
		container.addChild(new Bitmap(_renderTarget));

		_rect = new Rectangle(0, 0, _cellSize, _cellSize);
	}

	public inline function lock():Void
	{
		_renderTarget.lock();
		_renderTarget.fillRect(_renderTarget.rect, 0xff0000);
	}

	public inline function renderCell(x:Int, y:Int, isLive:Bool):Void
	{
		if (isLive)
		{
			_rect.x = x * _cellSize;
			_rect.y = y * _cellSize;
			_renderTarget.fillRect(_rect, 0);
		}
	}

	public inline function unlock():Void
	{
		_renderTarget.unlock();
	}

}

```

Will compile down to flash, c++ and Javascript! NME also includes packaging abilities for webos, android and ios. So with a few scripted command lines you can target most app marketplaces:

```

haxelib run nme test YourProject.nmml flash
haxelib run nme update YourProject.nmml ios
haxelib run nme test YourProject.nmml webos
haxelib run nme test YourProject.nmml android
haxelib run nme test YourProject.nmml cpp
haxelib run nme test YourProject.nmml cpp -64

```

What it means for this project is we could very quickly get a view for our game of life running in flash, JS and native desktop.

To show just how easy it is I made the following video:

<iframe width="853" height="480" src="https://www.youtube.com/embed/VNF2gH5o9Zs" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture"  allowfullscreen></iframe>

You can see the HTML5 build here: [/projects/gameoflife/Export/html5/bin/](/projects/gameoflife/Export/html5/bin/)

And the flash build here: [/projects/gameoflife/Export/flash/bin/MyApplication.swf](/projects/gameoflife/Export/flash/bin/MyApplication.swf)

I have uploaded the source for the project here: [/projects/gameoflife/gameoflife.zip](/projects/gameoflife/gameoflife.zip)

Final testing is under way here at mission control for the [Inputtie](https://www.inputtie.com) Beta.



[![](/wp-content/uploads/2010/09/photo1.jpg "photo")](/wp-content/uploads/2010/09/photo1.jpg)

1 Keyboard, 1 Mouse, 1 PC, 2 Laptops, 1 Netbook, 4 Operating Systems.

All systems are go! Almost ready for takeoff!