I'm totally new to this, am trying to implement a simple Unit Test example
I was reading Section 3 of Test-Driven Development with Games, and thought that unit testing would benefit us developers
link
http://gamesfromwithin.com/backwards-is-forward-making-better-games-with-test-driven-development
the example given was
// non-ImpactJS example
// test : if the player is not anywhere near the health powerup, its health stays the same
TEST (PlayersHealthDoesNotIncreaseWhileFarFromHealthPowerup)
{
World world;
const initialHealth = 60;
Player player(initialHealth);
world.Add(&player, Transform(AxisY, 0, Vector3(10,0,10)));
HealthPowerup powerup;
world.Add(&powerup, Transform(AxisY, 0, Vector3(-10,0,20)));
world.Update(0.1f); CHECK_EQUAL(initialHealth, player.GetHealth());
}
how would you implement the example above for ImpactJS?
it seems that all Impact files need to be loaded first before we can even spawn the health & player entities. This would cause the test to run slower (seconds instead of miliseconds )
I'm definitely missing something, and am totally new to unit testing.
@paularmstrong made a unit test wrapper for NodeJS+ImpactJS at
https://github.com/paularmstrong/ImpactTest . Does anyone have a simpler version without NodeJS? I think most devs here just deal with the offline ImpactJS version.
The ImpactTest package that I wrote is not specifically for Impact using Node... it's just using Node to run the tests so they can be run from a command-line without a browser.
I haven't tested it using the latest release of Impact, but I'd definitely recommend trying it out.
I’m not sure that I fully understand the question here. And I don’t really have to read that crazy long article, but I’ll try and help a little. :)
Having a test to see if the player is within range of something is easy. I have an entity that checks to see the distanceTo ig.game.player and if it’s so close do this, or this close do this. Kind of thing.
// Got this.distance set within the current entity.
// The below goes in the update function
if (this.distanceTo(ig.game.player).round() <= this.distance/3) {
ig.game.player.whatever = 3;
} else if (this.distanceTo(ig.game.player).round() <= this.distance/1.5) {
ig.game.player.whatever = 2;
} else if (this.distanceTo(ig.game.player).round() <= this.distance) {
ig.game.player.whatever = 1;
} else if (this.distanceTo(ig.game.player).round() <= this.distance+5) {
ig.game.player.whatever = 0;
}
// Your mileage with this will no doubt vary, but this is just an example. :)
@Hareesun the question I meant to pose was how do we create a test that runs extremely fast (miliseconds) to see if we've made any errors in coding.
Take, for example a single level. We want to simulate the player going through the entire level, and see if there're any hiccups. ( maybe an empty tile somewhere which might cause the player to fall into infinite space , or a jammed bullet, or the player etc ).
For a small game project, it might seem too much effort to create a test like this. But for larger projects, of say 200 levels, it might be hard to single-handedly test every one of them via human interaction, or even manually doing console.log each time.
Some of the points discussed in that article link might give clue to the requirements of such a test:
- it has to run extremely fast, without having to load the assets.
- the developer can call the tests any time, as many times as possible.
- the tests are meant as a guide to further enhance code. Hence, the term Test-Driven Development (TDD).
Having been a QA tester for Ubisoft… I’ll always trust a human playing through a game more so than writing some code to do it. :P
1 decade ago
by moonpxi
The point of TDD is not to fully test the game so we don't need humans anymore (although it is skynet's dream :)), it's more like a style of development:
- You write a test that verifies a desired outcome (e.g. when the player gets shot, health decreases).
- You run the test and it should fail, since you haven't implemented the behavior.
- You write the smallest possible code that makes the test pass.
- You run the test and it should pass.
- You refactor the code (e.g. remove duplication, make it less ugly, etc).
- Start again from the first step. :)
I have experience with TDD, but not with games + TDD. I find it a very valuable way of providing confidence in the code, and allows me to make changes without risk of undesirable behavior, even though it does seem counter intuitive and a waste at first.
I will definitely give it a try, after I buy ImpactJS, and I will report back.
ok looking forward to your tests!
1 decade ago
by linka
hey
here is a link that could be helpful to your discussion. its a blog of mine that issues with testing problems and automated software testing - take a look -
http://automatedtestingblog.com/
So my company has been working with a consultant to create games for us. We use TDD as part of our daily lives but the consultants were adamant that Games were too non-deterministic to test. So I can up with this skeleton solution for testing the ImpactJS framework in place with jasmine.
Given you develop your modules well your should be able to test any impact module with only reliance in the impact library. Its not perfect unit tests but its pretty easy to work with and can always branch into functional testing.
https://github.com/ninjapanzer/ImpactJS-TDD
Page 1 of 1
« first
« previous
next ›
last »