-
Notifications
You must be signed in to change notification settings - Fork 94
Testing
Before submitting a pull request, it is essential that the process outlined below is followed. Failure to do so may result in future pull requests being denied. The processes described here are intended to ensures a basic amount of stability before pull requests will be evaluated.
In general, testing the specific piece of functionality that has been modified is sufficient. For example, if a GUI for a specific block has been altered, there is no need to test the GUI for other blocks. That said, altering code in one place have unexpected effects on other areas at times, so testing other related areas is highly recommended. For example, when altering the shift click mechanic for a GUI, testing to make sure that the items are being saved and restored when the world is saved and re-loaded from saves.
- All blocks must be placed in the world.
- If blocks have a GUI, the GUI must be opened. See the GUI section below.
- If the block has a animation, it must be triggered.
- If the block has a texture, verify that it displays properly on all sides.
- All GUIs must be opened.
- If there are any interactive elements, eg buttons or sliders, they must be tested.
- For any GUIs with storage slots, items must be placed in the slots both via drag-and-drop and via shift clicking.
- Ensure that the item or block can be found via the search bar in NEI.
- Ensure that the recipe for the block or item displays correctly.
- If the item or block is used in any recipes, make sure the derivative recipe(s) display properly.
- If adding an item, ensure that the appropriate entry is added in the en_US language file. (Efforts should be made to update the other language files. However, the English language entry is absolutely required).
- If changing an item or language entry, ensure that the change shows up ingame.
- Check to make sure that the world saves properly.
- Check to make sure that the world loads properly.
- Create a world using a previous version of the mod, and ensure it loads properly.
- All non-temporary debugging code is placed inside a check for the "Settings.DebugMode" boolean.
Code formatting can be a touchy subject. Personally, I like it to be simple and readable. That said, there's a few things that I'm going to request.
- Use brackets when coding if/else/while/for/etc.
- Name variables descriptively (pull requests with par1/par2Str/par3int in changed code will be rejected).
- Indent in a sane manner.
- Comment your code when doing something that isn't obvious or straightforward.