No but if you watch their twitch streams there is a chance you’ll get to see it! It’s not Unit Testing the terms that we think (as developers) but they setup scenarios, issue commands, and see if the hearthlings respond accordingly. Tom has had moments in streams where he implements a new change (performance change usually) and runs the tests to ensure nothing else broke while he gets another cup of coffee Not sure if we can summon @sdee@Tom@yshan to explain it more technically
I know because a lot of the gui is Javascript (don’t quote me on that but I know you can debug in chrome) they’re able to setup commands relatively easy…like i said don’t quote me on that I’ve only seen it running ;p
As a fellow developer you’d probably glean some insight and definitely would enjoy the Wednesday streams! (I think it’s wednesdays…time for more coffee)
Hey @Nolic0321, just wanted to correct/add to a couple of your points. First, it is Tony (@Ponder) who does the Wednesday streams, and whom you have likely seen doing Performance related work. Tom (@Tom) mainly does design related things, and usually streams on Tuesday and Thursday evenings (though sometimes Yang and Stephanie stream then instead). The GUI is a combination of HTML, CSS, and Javascript!
Now, to @theWul’s question: a unit test is (quick description here) a script, program, or sometimes even a user testing a small, specific part of a program to ensure that it functions as expected. Going to use a very offtopic example, but let’s say you were developing a calculator. The first thing you make, let say, is the UI. A bunch of buttons and a “screen”. Then you make addition work. Now, after testing addition, you code subtraction. A unit test you might complete now is 2+2, and ensure it still equals 4. If it doesn’t, then something went wrong when coding subtraction. If it works, you go on and develop multiplication. You would complete the same test (2+2), and maybe 2-2 to track subtraction. As you develop more features, you continue to run the same unit tests to ensure there are no major regressions.
In terms of Stonehearth, Team Radiant has developed a series of “auto-tests” that test individual features of the game every time new code is added in. Features that are tested (just a subset) are hauling, storage, placement, combat, pathfinding, and more. Any time you watch a stream and see the game “playing itself”, those are the autotests.
For some general info on unit tests, check out this wikipedia article:
Hrhr - thanks for compiling the above on unit tests =)
I’m very well aware of what unit tests are, having implemented more then enough.
The problem imho is that you can build unit tests only for use cases you anticipate - of course this leads to a better understanding of your component/module, and usually improves the code, but later on they dont help very much - in my experience very few programming errors actually gets trapped in unit test.
So I was just curious how a unit test for the pathfinder or the builder would be constructed =)
Lol I knew i’d mess up a whole slew of things! Thanks for the help @jomaxro…really gotta do my homework i get them confused…their too similar but not ;p
maybe i just misunderstood you, but isn’t that the entire point of an alpha/beta, so that other people can test the game/program you’re making and find asll the problems that a unit test doesn’t find?
Both of you (Bruno, Crab) are right, of course!
And exactly that “bugs found in Alpha/Beta” point closes the circle to the subject of this post: if this was my project I wouldnt dare to add anything new before some crucial problems are solved. Picking the combat related ones was unlucky, as there (rightfully) are different opinions on this subject.
But fixing pathinfinding, memory problems and the various issues around building should be addressed before any new feature, this stands as called =)
Anyway, as written earlier: I ve been convinced to have faith and trust radiant to have the resources for all they try to do…
Not sure if we can summon @sdee @Tom @yshan to explain it more technically