-
Notifications
You must be signed in to change notification settings - Fork 4
8. FAQ
- Writing tests for your code can give you greater confidence that your code does what its supposed to do by exposing bugs early.
- It can alert you if new bugs are created if a test used to pass, but now fails, due to changes you have made.
- You can follow a test-driven approach by writing your tests first, and then developing the code under test until all of the specs pass; when they do, you're done.
- Writing unit tests can simplify other testing when you have a high degree of confidence in each unit. When your functions perform possibly complex functions or are expected to return complex objects (like ObjectReferences or arrays), this kind of confidence can ease a lot of other testing burdens later.
- It will take longer to finish your mod. Writing unit tests means you are investing in the tests, both up-front and to maintain them over time, just like any other part of your mod. Because of this, for many simple mods, unit tests are likely not worth the effort to mod developers.
Lilac for Skyrim and Fallout 4 do not require any external dependencies.
Yes! Lilac has very high unit test coverage using itself. These are defined in lilac_test.psc. You can download the latest LilacTestLilac package, load LilacTestLilac.esp, and run startquest LilacTests to run the tests.
My code would be really difficult to test because my functions just do things, and don't return anything, or they do lots of unrelated things.
Unit testing can help you think about ways of improving the design of your code. You should refactor your code in order to make it more testable. This is a natural, beneficial byproduct of unit testing. As you are developing, keep in mind, "How am I going to test this?" As a rule of thumb, if something is hard to test, the code needs to change instead of making overly-complex tests. See this page for more info.
Lilac was primarily designed for unit testing. However, it is possible to write end-to-end integration tests. Just be careful with timing so that you don't have false positive / negative test results.
When developing Lilac, I tried to balance how easy or difficult Lilac was to install, write tests for, and run, taking into account the restrictions of the Papyrus language and the Creation Engine. Since I needed Lilac's test runner to keep track of certain state variables (like how many tests have passed or failed), combined with the easy way to run tests in game using the startquest console command, making Lilac a script you extend and attach to a quest made the most sense. Global functions, for instance, cannot maintain state because they can't access properties or variables outside of the function.
Due to Papyrus's restrictive nature, there are some things you might be used to in Jasmine that you can't do here.
- To have test suite-specific
beforeEachandafterEachfunctions, write your own functions for them and make sure to call them at the beginning / end of your test cases. (Using different states to toggle between different beforeEach/afterEach behavior will not work and will break your test.) - You can't skip tests with
xdescribeorxit. To skip them, comment out the line. - You can't run tests first / exclusively with
fit. All specs will be executed. - You can't nest
describeoritfunctions.
-
beforeEachandafterEachare run one time more than there are test cases. (For example, if you have 5 test cases, these functions will run 6 times.) Just make sure that your tests are very decoupled and that nothing will break ifbeforeEachandafterEachare run without a test in between.
- They can be faked using inheritance or by leveraging script States. See the Mocks page for more info.
Yes, and yes.
Lilac is licensed under the MIT License.