Unit testing
Re: Unit testing
Just sneaked out v1.3:
* added: simularTo( ) and notSimilarTo( ) assertions
* fixed: bug in Test.UNIT_TIMEOUT value
Right, back to Util API...
* added: simularTo( ) and notSimilarTo( ) assertions
* fixed: bug in Test.UNIT_TIMEOUT value
Right, back to Util API...
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
-- https://warzone.atlassian.net/wiki/display/GO
Re: Unit testing
It just prototypy of sintax.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?
Code: Select all
In wz code
Test.run (test1)
test1 is nameof test function
function test1()
function setup
function tearDown
function testThat
function dosomthing
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.
http://addons.wz2100.net/ developer
Re: Unit testing
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
Also, what do you think of BDD style test scripts, something like this: https://github.com/joshuaclayton/specit ... E.markdown
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
-- https://warzone.atlassian.net/wiki/display/GO
Re: Unit testing
Looks like you link is example.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
In my python projects use unittest. I like it for easy syntax.
http://docs.python.org/2/library/unittest.html
http://addons.wz2100.net/ developer
Re: Unit testing
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.
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.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
-- https://warzone.atlassian.net/wiki/display/GO
Re: Unit testing
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:
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.
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'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.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
-- https://warzone.atlassian.net/wiki/display/GO
Re: Unit testing
@Duha - could you take a look at this and let me know what you think? https://warzone.atlassian.net/wiki/disp ... +direction
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
-- https://warzone.atlassian.net/wiki/display/GO
Re: Unit testing
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.
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
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...
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...
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
-- https://warzone.atlassian.net/wiki/display/GO
Re: Unit testing
I was on vacations. mobile device is not good to inspect code.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 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:
Spoiler:
Spoiler:
http://addons.wz2100.net/ developer
Re: Unit testing
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.
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.
"Dedicated to discovering Warzone artefacts, and sharing them freely for the benefit of the community."
-- https://warzone.atlassian.net/wiki/display/GO
-- https://warzone.atlassian.net/wiki/display/GO
Re: Unit testing
You just need to import all test classes to you scope.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?
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 manual running from code somthing like that:
Code: Select all
test.run()
test.run('RobotTest')
test.run('RobotTest.testOne')
http://addons.wz2100.net/ developer