Files
vgstation13/code/modules/unit_tests
Hinaichigo 15c7603524 Grues Revisited (#31687)
* Base of grues.

* Few more updates to grues

* Bit more work on grues.

* Bit more work on grues, namely getting them to evolve and reproduce properly.

* A few additions to gures and also to simple mobs to allow for delayed airlock forcing.
Egg hatching and upgraded stats with every sentient being eaten.

* Few additions to grues including a grue language and gruevision to see in the dark.

* Several changes to grues, including adding their antag roles (still need to be tested/debugged).

* Finalized the base of grues including a nicer-looking grue vision.
Some stuff remains to be tested and debugged.

* Removed obsolete file.

* Updated vgstation.dme with grue additions

* Update vgstation13.dme

* Update grue.dm

* modify .dme

* typo

* remove unneeded variable

* Added gore globs from those eaten by grues that can be cloned or brain extracted. Also fixed some bugs preventing slime puddles from being put in a cloner. Had to generalize a bunch of code in various places to do this (eg. moving certain procs and variable definitions from /mob/living/carbon/ to just /mob/living/)

* Removed gore globs after being eaten by a grue; a head remains by default so it's not needed.
Also debugged slime puddle cloning.

* -grue egglaying is set to a config option
-few modifications to grue antag objectives

* Added changelog and some UI tweaks.

* Update misc_structures.dm

* Update misc_structures.dm

* Juvenile grues can force open doors as well. Also added some more descriptive text upon moulting. Fixed airlock code bug.

* Update grue.dm

* Delete nulllight.ogg

* Fixed up grue sound effects. Renamed humanoid grue to umbra.

* more grue/umbra split stuff

* Update Hinaichigo.yml

* Adult grues can force airlocks open instantly.

* Changed role greet messages from 'danger' to 'warning'.
Explitized empty lists in grue gamemode variables.

* Update grue_egg.dm

* Few fixes to grues.

* Used defines for lifestage checks.
Reverted organ changes and removed an unneeded(?) check from cloner code.

* Migrated grue abilities into spells framework.
Made umbras (humanoids formerly called grues) in the same faction as grues.

* .

* Grue spell icons

* .

* Custom blood and meat colors for mobs.
Grue meat contains a certain substance.

* Removed gore globs.

* .

* Meat coloring + related food unit test fixes.

* Update icons.dm

* Bugfix with custom meat colors.

* .

* Grue abilities panel+sprites.

* .

* Fixed up grue role/objectives.

* .

* Sprite tweak.

* .

* New sfx for moulting and burning in light.

* .

* fixed icon conflict

* .

* icon conflict fix

* More descriptive variable names. A few tweaks to stats.
2022-01-21 10:08:07 +00:00
..
2021-10-11 11:56:44 -05:00
2020-12-18 18:02:49 -06:00
2022-01-21 10:08:07 +00:00
2021-10-16 02:43:46 -05:00

What is this?

These are tests. Tests are just procs that run any number of checks and might call the fail() proc. If that happens, it is said the test failed, and a test failing means your changes cannot be merged.

How do I write a test?

Define a new /datum/unit_test subtype. The only requirement for a unit test datum is that you override the start() proc. Your test might look something like this:

/datum/unit_test/my_feature/start()
    var/obj/item/my_feature/object = new
    if(object.this_proc_should_return_one_when_passed_zero(0) != 1)
        fail("[object.type] did not return 1 when it was supposed to!")

Put that into a new file in this directory, then add that file to __unit_test_includes.dm:

...
#include "my_feature.dm"
...

That's mostly it. Additional documentation is available in _unit_test.dm.

Anything else I need to know?

  • Runtime errors that happen while your test is running will automatically fail() with a detailed error message.
  • Unit tests are not compiled by default, they have to be enabled in __DEFINES/__compile_options.dm.
  • You can easily check the result of unit tests using the "Unit test report" verb, under the Debug category.

Why would I want to do this?

The guarantees that the DM compiler can grant you are not many: code that compiles doesn't necessarily mean it will do what you intended it to, at run-time. Unit testing helps you gain some confidence that your code works. Not only that: if your_feature gets changed in the future, or if changes are done to some system your_feature depended on, a test will let you know before the damage is done.