NM8H2MND1Z: Unit Testing Framework for FUZE 2.15

PB____

This one is not about a single function, but I think it fits here anyway.
Because I've written a new unit testing framework in FUZE 2.15.
ID: NM8H2MND1Z (pending, because I did a last minute improvement to it)

The idea is that you write your tests as a recipe that describes the behavior of your code.
Things that are for internal use start with test__ (double underscore) and things that are there to be used in unit tests start with test_ (single underscore).

// functions to document what is being tested
test_describe(string description) describe what your unit test will test (for example the name of your function)
test_it(string behavior) describe the behavior you verify in the next (few) assertion(s)
test_note(string comment) add a comment (for example to explain why you've included a specific assertion in the test)
// functions to verify behavior
test_assertEquals(value1, value2) // verify that value1 and value2 are the same (it will not check for types, so "1" will be equal to 1)
test_assertNotEquals(value1, value2) // opposite of test_assertEquals
test_assertLess(value1, value2) // verify that value1 < value2 results in true
test_assertLessEqual(value1, value2) // verify that value1 <= value2 is true
test_assertGreater(value1, value2) // verify that value1 > value2 is true
test_assertGreaterEqual(value1, value2) // verify that value1 >= value2 is true

Unit tests can be helpful for example when you are refactoring a function (changing the implementation while the behavior should remain the same). If you have a good test for the function, then you can spot if the tests stay "green" after changing your function.

Also if there would be more breaking changes of FUZE in the future, a unit test can help to verify that your code still works after the update.

It can also help to "document" known issues with code.

You could also do test driven development. In that case, you first write the unit tests for your empty functions according to the behavior that you want to implement. And once you have the tests, you can implement the empty functions, so the tests will become green.

pianofire

Minor issue but when there is less than a screen full of results they display at the bottom

PB____

Thanks for the feedback. I've shared an update (pending) that fixes this.

In addition I've now added that you can run multiple modules of unit tests like this:

function testModuleOne()
    test_init() // start with a clean context (in case of multiple test modules)

    test_describe("module one")
    test_it("calculates the answer to the ultimate question of life, the universe and everything")
    test_assertEquals("still calculating, ask again in 7.5 million years", 42)

    test_result() // show results on screen
return void

function testModuleTwo()
    test_init() // start with a clean context (in case of multiple test modules)

    test_describe("module two")
    test_it("has an answer now")
    test_note("asking again is enough, you don't need to wait 7.5 million years to get the answer.")
    test_assertEquals(42, 42)

    test_result() // show results on screen
return void

testModuleOne()
testModuleTwo()

Then when running the program, you can press x to close the results of module one, and start the test of module 2.

I've also added a regression test in the program it self, by adding a test that tests the unit test that tests the unit test framework. So the first results show more than one screen of results, while the second results summarizes if the test succeeded :)

By the way, I also shared the linked list program that I created and test with this framework, it has game id N5WYAMND1Z. It is a working linked list, but should not be used in actual projects, because it has no reason to exist under the current limitations :)

PB____

Needed to follow it up with a third update. If you write multiple unit test modules, you need to call test_init() first (to make sure your test starts with a clean context)