1
1
2
2
# MoonScript spec guide
3
3
4
+ ## Testing the right code
5
+
4
6
Because MoonScript is written in MoonScript, and MoonScript specs are written
5
7
in MoonScript, you need to be aware of which copy of MoonScript is actually
6
8
executing the specs.
@@ -19,9 +21,14 @@ MoonScript available in the load path:
19
21
When developing you want to make ensure the tests are executing your changes in
20
22
the current directory, and not testing the system install.
21
23
22
- Code running in Busted will have the system install take precedence over the
23
- loaded version. That means that if you ` require "moonscript.base" ` for a test,
24
- you won't get the local copy.
24
+ Busted itself is MoonScript aware, so it means it should have a functional
25
+ MoonScript compiler in order to load the ` .moon ` test files. This should be the
26
+ system install. After booting your specs though, you would like to use the
27
+ current directory version of MoonScript to the test
28
+
29
+ Because by default Busted will have the system install take precedence over the
30
+ loaded version, running ` require "moonscript.base" ` within a test you won't get
31
+ the working directory version of the code that you should be testing.
25
32
26
33
The ` with_dev ` spec helper will ensure that any require calls within the spec
27
34
that ask for MoonScript modules. ` with_dev ` calls a setup and teardown that
@@ -40,7 +47,33 @@ describe "moonscript.base", ->
40
47
moonscript.load "print 12"
41
48
```
42
49
43
-
44
- ` with_dev ` 's require function will load the ` .lua ` files in the local
45
- directory, not the ` moon ` ones. You're responsible for compiling them first
50
+ Note that ` with_dev ` 's ` require ` function will not use the MoonLoader, it will
51
+ only load the ` .lua ` files in the working directory directory, not the ` moon `
52
+ ones. This means you must compile the working directory version of MoonScript
46
53
before running the tests.
54
+
55
+ There is a make task to conveniently do all of this:
56
+
57
+ ```
58
+ make test
59
+ ```
60
+
61
+ ## Building syntax tests
62
+
63
+ The test suite has a series of * syntax* tests (` spec/lang_spec.moon ` ) that
64
+ consist of a bunch of ` .moon ` files and their expected output. These files
65
+ should capture a large range of syntax that can be verified to have the correct
66
+ output when you make changes to the language.
67
+
68
+ If you are adding new syntax, or changing the expected output, then these tests
69
+ will fail until you rebuild the expected outputs. You can do this by running
70
+ the syntax test suite with the ` BUILD ` environment variable set.
71
+
72
+ There is a make task to conveniently do this:
73
+
74
+ ```
75
+ make build_test_outputs
76
+ ```
77
+
78
+
79
+
0 commit comments