Page 1 of 1

T - a multi-paradigm test framework

Posted: Wed Jun 24, 2015 1:30 pm
by 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.

Re: T - a multi-paradigm test framework

Posted: Sat Jun 27, 2015 4:46 am
by T-Bone
Can you give an example where this would be useful in game development?

Re: T - a multi-paradigm test framework

Posted: Sat Jun 27, 2015 10:29 am
by airstruck
T-Bone wrote: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.

Re: T - a multi-paradigm test framework

Posted: Thu May 31, 2018 4:04 pm
by SmartGlassesMan
airstruck wrote: Wed Jun 24, 2015 1:30 pm 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!

Re: T - a multi-paradigm test framework

Posted: Fri Jun 01, 2018 1:56 pm
by KayleMaster
Here you go: https://github.com/airstruck/knife/blob ... me/test.md
You can also check out busted.

Re: T - a multi-paradigm test framework

Posted: Fri Jun 01, 2018 3:50 pm
by SmartGlassesMan
KayleMaster wrote: Fri Jun 01, 2018 1:56 pm Here you go: https://github.com/airstruck/knife/blob ... me/test.md
You can also check out busted.
Thanks!