RailKill
commented
3 years ago I agree that the documentation is rather terse and not very readable at its current state where it is presented as comments within the script itself. I hope the old ReadTheDocs documentation can be restored; a well-formatted document will be much more helpful not just to newcomers, but for any user in terms of accessibility and readability. Many projects have a separate repository for the webdocs, perhaps @AlexDarigan can consider the value in this as the webdocs was what got me to try WAT in the first place during the 4.0 release.
Anyways, from what I can gather, the directors are used to setup the circumstances of your mock. I think line 3 of create_script_director.test.gd describes it best:
# Script Directors are used to instruct how a Test Double should operate.
double() is always called at the end of each test, meaning that it runs the mock. So the director (whether for a scene or script) is the setup, and the double is the executor. I don't think it assumes anything from GUT; it's more of a general thing in unit testing.
AlexDarigan
Hello, I'm looking at which test systems to pick right now and I have a hard time understanding WAT.
I'm sure I'm not the only one with such difficulties, so I thought I'd give suggestion for changes / additions that, I think, would make it easier for newcomers to get into WAT.
Took me a time to write all of this, please don't take it personally / as an attack:
A couple of places in the examples talk about making Directors. Yet, even doing a github search on the repo, I can't find an actual explanation of what they do / what is their role. Since they appear to be quite integral to the system, I believe it would greatly help to add a section in the main Readme or Wiki (with a link from Readme) just to explain what they are, what they do, why they should be used, etc. Right now, I have to just go back in forth through the couple of example to try to build an intuition about them.
The examples talk a lot about doubles, but you barely explain them. Looking at 5 different files to get a couple of lines of explanation is pretty painful. I guess your idea is that someone will come from GUT, having read their documentation. But if so, your doubles are actually their partial_double. This is information you mention somewhere in those 5 files that I had to hunt for.
The example project and its example tests not together. This makes things more confusing. I would suggest having a
/exampleand a/example/tests./testswould then be only for tests ofWATitself (I assume that's what bootstrap is).The example tests are not really example tests, they are example code. They are more of an attempt at documenting the features. As test, they don't make much sense. That's ok, but having actual tests that feel like test would be incredibly helpful. Real tests can be used as base template for the firsts tests of users, and to give an idea of a real tests to a reader.
It would be great to see some simple test where you check that the hero loses health when he bumps into an enemy, something that actually uses the scene. That would be a single example that shows how to do quite a bit of basic things with WAT. I would guess there is little need for even a using a double in that case, but I may be wrong.
I know documenting can be painful, I've spent quite a long time doing so in my public Ruby on Rails librairies. But writing it all down can really help new comers, and help you identify things that, maybe, could be better. If it's hard to explain, it might be worth it to simplify something first and then explain it.
The tools seems to be quite nice, but right now, it's hard for me to even want to figure out since I have plenty to figure out in Godot already.
Side note, the code for the first test in each of those files is identical: https://github.com/AlexDarigan/WAT/blob/main/tests/examples/gdscript/doubles/create_scene_director.test.gd https://github.com/AlexDarigan/WAT/blob/main/tests/examples/gdscript/doubles/create_scene_doubles.test.gd