T - a multi-paradigm test framework

[airstruck]

I wanted a test framework that would run subsections in isolation: for each "leaf" section of the scenario, the entire scenario runs, skipping all branches not connected to the current leaf. This kind of test framework eliminates the need for fixtures, and allows for creating BDD-style tests in an expressive, natural way.

This is much different from the nested sections in (for example) telescope... in those frameworks, the tests themselves cannot be nested (only the "context"), and the nested sections do not run in isolation.

Here's an example:

Code: Select all

T('Given a value of two', function (T)
  local value = 2
  T('When the value is increased by five', function (T)
    -- here, value is 2
    value = value + 5
    T:assert(value == 7, 'Then the value equals seven')
  end)
  T('When the value is decreased by five', function (T)
    -- value is 2 again; this test is isolated from the "increased by five" test
    value = value - 5
    T:assert(value == -3, 'Then the value equals negative three')
  end)
end)

That test effectively defines two scenarios, one for each leaf branch:

• Given a value of two
  When the value is increased by five
  Then the value equals seven

• Given a value of two
  When the value is decreased by five
  Then the value equals negative three

There aren't a lot of bells and whistles yet, but it gets the job done. Here's the source, I'll add documentation and examples at some point.

[T-Bone]

Can you give an example where this would be useful in game development?

[airstruck]

Can you give an example where this would be useful in game development?

Automated testing is useful in game development for the same reasons it's useful (essential, really) in any other kind of software development.

As far as feature tests go, writing a spec helps formalize intended behavior. When the spec is complete and the software conforms to the spec, you can have a high level of confidence that all features work properly.

As for unit tests, they can help ensure that the software is working on a more granular level, and if feature tests start failing during a change, unit tests can help you pinpoint the cause.

Once you have a test suite, you can quickly spot regressions at build time. You can also write a test for a new feature before the feature is implemented, implement the feature, then ensure the test passes (TDD). You can run the tests along with a code coverage tool like luacov to find dead code or identify code that doesn't execute when you thought it did.

That's not really an example so much as an explanation, but I hope it answers your question.

[SmartGlassesMan]

There aren't a lot of bells and whistles yet, but it gets the job done. Here's the source, I'll add documentation and examples at some point.

Hi! I realize that you did all of this free of charge and may not have had the time, but; have you released any of that documentation or those examples yet? Maybe I just missed them on the GitHub site.

Thanks!

[KayleMaster]

Here you go: https://github.com/airstruck/knife/blob ... me/test.md
You can also check out busted.

[SmartGlassesMan]

Here you go: https://github.com/airstruck/knife/blob ... me/test.md
You can also check out busted.

Thanks!