Page 3 of 3

Re: Unit testing

Posted: 28 Nov 2012, 01:39
by aubergine
Just sneaked out v1.3:

* added: simularTo( ) and notSimilarTo( ) assertions
* fixed: bug in Test.UNIT_TIMEOUT value

Right, back to Util API...

Re: Unit testing

Posted: 28 Nov 2012, 05:19
by Duha
aubergine wrote:So what style of testing should I be using? Can't just come out saying "its not pretty" and then not mention the better alternative?
It just prototypy of sintax.

Code: Select all

In wz code

Test.run (test1)

test1 is nameof test function
function test1()
  function setup
  function tearDown
  function testThat 
  function dosomthing
For each function that starts with test you call setup function before and teardown.
Test function can contain many assertation and other things. If assert fails it just raise exception.

It is style of junit of java and unittest in python.
Each test class or test method can be launched separetly.

Re: Unit testing

Posted: 28 Nov 2012, 05:59
by aubergine
Ok, I can probably implement something like that - do you have any links to examples of that style of test script?

Also, what do you think of BDD style test scripts, something like this: https://github.com/joshuaclayton/specit ... E.markdown

Re: Unit testing

Posted: 28 Nov 2012, 11:43
by Duha
aubergine wrote:Ok, I can probably implement something like that - do you have any links to examples of that style of test script?

Also, what do you think of BDD style test scripts, something like this: https://github.com/joshuaclayton/specit ... E.markdown
Looks like you link is example.

In my python projects use unittest. I like it for easy syntax.
http://docs.python.org/2/library/unittest.html

Re: Unit testing

Posted: 29 Nov 2012, 06:09
by aubergine
Just spotted huge blunder in assertions - the actual/expected params were wrong way round in all of them.

I've updated documentation but not yet uploaded v1.4 of the API - will upload new versions to git tomorrow.

Apologies for any pain caused.

Re: Unit testing

Posted: 29 Nov 2012, 18:36
by aubergine
Test API v1.4 uploaded to git: https://github.com/aubergine10/EggPlant

Note the order of expected/actual params on all assertions has been changed to actual, expected (was expected, actual) -- if you've made any test scripts using this API, please update them. Sorry for the pain, but it's to keep the assertions in same format as QUnit where possible.

With the similarTo() and notSimilarTo() assertions, I've added some constants: Test.FOUND and Test.NOT_FOUND as detailed in the docs:

* https://warzone.atlassian.net/wiki/page ... d=16777272
* https://warzone.atlassian.net/wiki/page ... d=16777274

With regard to using the constants on the notSimilarTo() assertion, I'm keen to get feedback as to whether they "sound right" when used in that context?

For example, these tests will pass because actual value is not similar to expected value:

Code: Select all

notSimilarTo( {a:1, c:3}, {a:5}, "actual.a != 5" );
notSimilarTo( {a:1, c:3}, {b:Test.FOUND}, "actual.b != found" );
notSimilarTo( {a:5, b:1, c:3, d:2}, {d:Test.NOT_FOUND}, "actual.d != not found" );
I wasn't sure whether to invert the meaning of the constants when used in notSimilarTo() -- any comments?

I've left similarTo() and notSimilarTo() marked as "beta" in the docs for now, they are both tested and work, but I want to see if anyone has any better ideas about the constants before treating them as final.

Re: Unit testing

Posted: 29 Nov 2012, 23:59
by aubergine
@Duha - could you take a look at this and let me know what you think? https://warzone.atlassian.net/wiki/disp ... +direction

Re: Unit testing

Posted: 08 Dec 2012, 12:52
by Per
I have been thinking about making a unit testing map with its own javascript that would run various calls automatically, and then ask the user to do various things to trigger things that cannot easily be tested automatically. This map could be added to the distribution and be run as part of the commit changes to scripting / official release procedure.

If anyone want to have a go at this, it would be nice. I can add a hackAssert(condition, message...) function for it.

Re: Unit testing

Posted: 08 Dec 2012, 12:55
by aubergine
Could that not be done with a challenge map and do the unit testing in JS?

What would the hackAssert() function do?

EDIT: BTW, I've been pondering something similar, perhaps even using audio prompts and console messages to guide the user through the testing process. I was also thinking similar technique could be used to create a series of tutorial maps...

Re: Unit testing

Posted: 08 Dec 2012, 20:22
by Duha
aubergine wrote:@Duha - could you take a look at this and let me know what you think? https://warzone.atlassian.net/wiki/disp ... +direction
I was on vacations. mobile device is not good to inspect code.

I write some code as example of that I like.

Big peace of code just insert it to js test. (it can be run in any js enviroment just change "console" to other output.) (dont try to read it, coffescript interpretator writes cod not for reading :))
Spoiler:
Sample of the test
Spoiler:
coffescript
Spoiler:

Re: Unit testing

Posted: 09 Dec 2012, 01:08
by aubergine
And what would happen if you had lots of test scripts and wanted to split them out in to separate .js files? Variables like __extends, etc., would need to be put on to the global scope, unless you propose that all tests are put in to one massive .js file?

Anyway, I can see the type of syntax & extensibility you are looking for and will add it to my list of future updates to my Test API. My current focus is just on getting more of my APIs released with testing under the current Test API framework.

Re: Unit testing

Posted: 09 Dec 2012, 07:31
by Duha
aubergine wrote:And what would happen if you had lots of test scripts and wanted to split them out in to separate .js files? Variables like __extends, etc., would need to be put on to the global scope, unless you propose that all tests are put in to one massive .js file?
You just need to import all test classes to you scope.

I this is manual way, but it is should not be used.

Code: Select all

test1 = new RobotTest('robot');
test2 = new TruckTest('truck');
res = new Runner([test1, test2]);


Normal way should be lookes something like that:

Code: Select all

wz.exe -test // all test
wz.exe -test RobotTest // all test in class
wz.exe -test RobotTest.testOne //current test
and get output to console. In that case autotest will be real autotests. And can be integrated to build system.

And manual running from code somthing like that:

Code: Select all

test.run()
test.run('RobotTest')
test.run('RobotTest.testOne')