# rokudev/unit-testing-framework: an imaginary solution **URL:** \ **Category:** Archived\ **Tags:** roku-developer-program\ **Created:** [January 1, 2017, 9:59pm UTC](https://forum.developer.roku.com/t/rokudev-unit-testing-framework-an-imaginary-solution/7682 "2017-01-01T21:59:42Z")\ **Posts on this page:** 2\ **Page:** 1
**Author:** ![EnTerr](https://avatars.discourse-cdn.com/v4/letter/e/ba9def/32.png) [@EnTerr](https://forum.developer.roku.com/u/EnTerr)\ **Post date:** [January 1, 2017, 9:59pm UTC](https://forum.developer.roku.com/t/rokudev-unit-testing-framework-an-imaginary-solution/7682/1 "2017-01-01T21:59:42Z")
There is this “[Unit Testing Framework](https://github.com/rokudev/unit-testing-framework)” by RokuCo, which apparently has been available for almost 5 months now. I had deeper look yesterday and to summarize my conclusion, it is “an imaginary solution to a real need”^. No wonder it has never been officially announced. First, I won’t grade it on good/bad scale - it is beyond the categories of “good” and “bad” - it simply does not work. It would be like discussing “gas mileage” on a car that won’t start - well i don’t know what’s the MPG, since it hasn’t driven even a mile yet. I discovered that critical functions are missing - e.g. _FW\_isAssociativeArray, FW\_isАrray_. The July 2016 delivery was apparently a “drop and run” event - if somebody from the Co had bothered downloading and testing the repository, they’d know it won’t run. Now there are good news, in that at least somebody did care after all - mostly @siekermantechno logy, who took the lib for a spin in November and logged the 11 issues (including the missing files, [#2](https://github.com/rokudev/unit-testing-framework/issues/2) and [#7](https://github.com/rokudev/unit-testing-framework/issues/7)), which have been blissfully ignored so far (hello?! Quo vadis, RokuCo “evangelists” and “developer experience managers”?). Luckily, he found a way to recover the missing files from elsewhere - and [so did @cdthompson](https://github.com/rokudev/unit-testing-framework/issues/2#issuecomment-269871781). I am no big fan of XUnit kind of frameworks - they seem to me too much “form” and not enough “substance”. Were i a “100% QA engineer”, i might think different. However, i value the ability to verify functionality down to function level. TDD^^ style of work also has a very solid point! I read the source of one of the files - [fw\_baseTestSuite.brs](https://github.com/rokudev/unit-testing-framework/blob/master/fw_baseTestSuite.brs) - so consider the following a peer-review notes: - _[BTS\_\_AssertArrayContainsOnly](https://github.com/rokudev/unit-testing-framework/blob/28d8154fa688cd5683035528ff014e005d2124eb/fw_baseTestSuite.brs#L549-L551)_() can’t possibly work! Really? You think a function can dynamically be called like `("FW_Is" + typeStr)(item)`? That’s adorable! Where do you think we are - Narnia? Tcl? Apparently never tested. - _[BTS\_\_EqValues](https://github.com/rokudev/unit-testing-framework/blob/28d8154fa688cd5683035528ff014e005d2124eb/fw_baseTestSuite.brs#L577-L606)_ is unusable. Shows lack of understanding of the numeric types (hint: besides roFloat and roInt, there are also Integer, Float, Double, roDouble, LongInteger…) - try and see the following fail: (1, 1.0), (1, box(1)), (1, 1&), (1e, 1d). It also won’t work with String vs roString, try (“12”, “1”+“2”). Very sloppy, harmful code actually. Also, it would crash when called with [incomparable](https://www.youtube.com/watch?v=BB1TKw8_b1s) types, say BTS\_\_EqValues(global, global) or BTS\_\_EqValues(myPort, myPort) - No point having _AssertArrayCount_(arr, cnt, msg), since can always do assert(arr.count() = cnt, msg) instead. Ditto _AssertArrayNotCount_() - _BTS\_\_AssertEmpty_(), BTS\_\_AssertNotEmpty do not fail when called with wrong type arguments (they should) - _AssertEmpty(), AssertNoEmpty_() make no sense: nobody said “you know what would be great - if there were 1 function that can check both arrays and string for ‘emptiness’ - but no other types”. Instead just use assert(var=“”, msg) and assert(var.count()=0, msg) - BTS\_\_EqAssocArray and BTS\_\_EqArray don’t check they were indeed passed AA and array, breaking tradition (^) yes, i meant “imaginary” and not “imaginative” - my English is not _that_ bad. It couldn’t have been _imaginative_, since it’s just attempt at hammering something JUnit/NUnit-alike for B/S - something that was done 7 years ago by Mark Roddy, see [viewtopic.php?f=34&t=25722](https://forums.roku.com/viewtopic.php?f=34&t=25722). That’s right, _seven_ years - beginning of 2010! PS. and now that i had quick glace at [BrsTest](https://github.com/MarkRoddy/brstest/blob/master/source/brstest.brs), well… i notice portions of code&comments that unit-testing-framework has taken from there without giving due copyright credit. Talk about being ungrateful to open source… technically that’s illegal? (^^) “Test-Driven Development”, in which you write first the expectations how a functionality should work - and then “all you have to do” is fill out the function/method with code that makes the test cases run successfully. That keeps you honest about what the fn does - and also flags you when to stop (if there is no failing case, we are done). Plus it stays for later to catch refactoring when it back-fires (AKA regression testing). ---
**Author:** ![EnTerr](https://avatars.discourse-cdn.com/v4/letter/e/ba9def/32.png) [@EnTerr](https://forum.developer.roku.com/u/EnTerr)\ **Post date:** [January 2, 2017, 9:38pm UTC](https://forum.developer.roku.com/t/rokudev-unit-testing-framework-an-imaginary-solution/7682/2 "2017-01-02T21:38:49Z")
Ha - there is a great example of how not to use eval(): > “[fw\_testRunner.brs#L208](https://github.com/rokudev/unit-testing-framework/blob/31c21a1af5b23f633699b5e0cb4ba91e9c79d35b/fw_testRunner.brs#L208)” wrote: > > eval(“testSuite=” + functionName + “()”) > Basically the equivalent of BASIC’s “_ON ERROR RESUME NEXT_” or `_try { ... } catch(ignore) { /* nada */ }_` - call it and never bother to check if there was an error. I noticed that and chuckled at it - but later saw that somebody suffered it in real life too, [issue #9](https://github.com/rokudev/unit-testing-framework/issues/9)