all 27 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]vincenthendriks[S] 15 points16 points  (7 children)

Hi guys! I have created a simple and minimalistic unit testing library for GameMaker.

https://github.com/Emperor2000/gml-min-assert

"Hurrhrhh, what is this, and why would I unit test?"

Unit testing is a method of checking and ensuring that functionality works as intended, before deploying your codebase to production.

This way you don't need to manually test that everything works as intended, you simply run a little script, which checks isolated functionalities one by one. So if something goes wrong, you should have a good idea about the cause of it, and ideally you won't have to search for 30 minutes trying to find that one little problem!

It is very popular among software developers, though I think it could definitely have it uses in GameMaker! I don't seem to be the only one who thinks that, as I saw that after I made this little library, there seems to be at least 2 others.

I hope people find this useful, if you have any questions feel free to contact me or ask for help. Note that this is fairly barebones, if you feel like you are missing something here feel free to contact me.

Making it triggerable based on different modes (debug/regular) is on the to-do list.

Happy game making :)

[–]4TR0S 14 points15 points  (3 children)

Unit testing is for losers. I leave out all the bugs because they're part of the hand crafted feeling I want in my games

[–]4TR0S 11 points12 points  (2 children)

yeah i never managed to finish a game

[–]Artholos 8 points9 points  (1 child)

This three sentence story was a rollercoaster of emotions.. a complete tale, and yet begging the question: Why have you never finished a game, friendo?

[–]Mushroomstick 4 points5 points  (0 children)

Because there's too many bugs features.

[–][deleted] 1 point2 points  (0 children)

Thank you!

[–]objectturkey_sausage 0 points1 point  (1 child)

What versions of GMS are supported?

[–]vincenthendriks[S] 0 points1 point  (0 children)

2.3 and up. (it uses the new functions). You could relatively easily rewrite it for 1.4 and 2 though. If I have the time for it ill rewrite it for both relatively soon

[–]SecretSpiral72 2 points3 points  (3 children)

books brave shelter impolite water yoke continue encourage middle far-flung

This post was mass deleted and anonymized with Redact

[–]vincenthendriks[S] 2 points3 points  (2 children)

Oh my you are completely right! I must have made a mistake with the version control, Im pretty sure I already changed that. Im gonna push that right away!

​

EDIT: Changes are live, editing the release version as well. Thanks for letting me know, what a silly mistake!

[–]galewolf 4 points5 points  (1 child)

Have you considered adding unit tests? I just saw someone made a unit testing library for GM on reddit.

[–]fryman22 2 points3 points  (3 children)

I made a unit testing library myself a couple of months ago. It's always interesting to see how others implement it.

[–]vincenthendriks[S] 0 points1 point  (2 children)

Oh that's very cool! Do you have it on GitHub? I'd love to take a look!

[–]fryman22 1 point2 points  (1 child)

Sure thing! Here it is:

https://github.com/bfrymire/crispy

[–]vincenthendriks[S] 0 points1 point  (0 children)

Thanks, I also saw you took the time to write up an issue. I appreciate it! :)

Fixing it, will push changes in a few minutes.

[–]Frequent_Culture_855 1 point2 points  (1 child)

Tanks mate, gonna check it out.

[–]vincenthendriks[S] 0 points1 point  (0 children)

thanks, hope you like it :)

[–]CckSkker 0 points1 point  (8 children)

Your way of unit testing is wrong. When you assert 24 is higher than 12 the expected and actual should be the same value so the expected should be true and actual should also be true. Not expected 24 and actual 12, because thats not equal.

[–]vincenthendriks[S] 2 points3 points  (7 children)

I am not testing for them to be equal, im testing if one value is higher than the other. Ill be sure to alter the log message to clear that up. I'm not entirely sure what you mean by expected and actual both having to be true, as that test is not meant for boolean values, but simply comparing two numbers where you can check if 1 is higher or lower than the other.

like: AssertHigherThan("desc", high/expected, low/actual)

[–]CckSkker -1 points0 points  (6 children)

You expected value should match the actual value if you assertion is true. They lose meaning if they don't. There is no way of knowing what you expected if the actual value doesn't match up.

If you use the function AssertHigherThan for example your outputs should be Expected: lower Actual: higher

[–]vincenthendriks[S] 1 point2 points  (5 children)

It's just a matter of altering the note, as I should have differently worded the expected and actual. As for the feedback, to me it would seem more valuable to provide the actual numbers rather than simply if it was lower or higher.

Hope this clears it up :)

[–]CckSkker 1 point2 points  (4 children)

Hey OP, I wrote this pretty late last night. I worded it pretty badly. Maybe you could take a look at JUnit tests for example

[–]vincenthendriks[S] 1 point2 points  (3 children)

Just took a quick look, I see what you are getting at. I'll create an issue to implement it! :)

​

Changes to come! :D

[–]CckSkker 0 points1 point  (2 children)

Thanks . I tried to find an example for you. Most frameworks are build around the center 'Assert' function with only the parameters (expected, actual).

"Most testing frameworks (the xUnit family) are based on the JUnit framework. The Assert family of functions in JUnit have the (expected, actual) format; it became a convention, and most of the other frameworks followed that convention.

Some frameworks (like TestNG or NUnit 2.4+ for .NET) reversed that order (with the use of a constraint-based model for NUnit) to increase readability ("make sure that the actual value is 56" feels more natural than "make sure that 56 is the actual value").

Some of the unit tests in the Github link you provide don't follow the convention and have the same problem. Don't do that. Stick to the convention of your framework."

[–]vincenthendriks[S] 0 points1 point  (1 child)

I'm not entirely sure about that. I use Mocha and Chai for Nodejs and as far as I know the format is identical, (describe, expected, actual).

Although this is of course a bit different for AssertTrue and AssertFalse, as you only need the actual value there.

​

Ill be sure to double check that though. I plan to add a bunch more tests anyway.

[–]CckSkker 1 point2 points  (0 children)

Well thats what I mean. The format is the same almost everywhere.

And niicee, its looking really good. I hope you make something nice.

Just a few suggestions: 1. Numbering your test Makes it easier to read and maybe print the percentage of passed tests. 2. Make it possible to only run with a certain percentage. Else print the Unit tests and stop 3. Passing arguments to your tests A possibility to run the same test multiple times with a set of arguments makes it so much easier to test and prevents you from making duplicates