As with all software development, not just Blender add-on development, it's a hassle to make sure it works every time you update the source code.
In this article, I'll show you how to use GitHub and Travis CI to automate the testing of Blender add-ons.
This article uses the CI (Continuous Integration) service ** Travis CI ** and the hosting service ** GitHub ** for test automation. Explaining how to use GitHub and Travis CI here will be lengthy, so I will omit it. There are many articles on the web about GitHub and Travis CI, so please refer to them and prepare until you can do the following.
For GitHub and Travis CI, for example, the following sites may be helpful.
Below is the file structure for testing Blender add-ons with Travis CI.
/ #Repository root directory
├ .travis.yml #Configuration file for Travis CI
├ test_addon.py #Add-ons to test
├ run_tests.py #Scripts that call individual tests
├ test_1.py # test_addon.py test script
└ test_1.blend # test_1.For py.blend file
Create an add-on to test. Name the file `` `test_addon.py```. It's a simple add-on with one operation class to test. Please refer to the following article for how to make an add-on.
test_addon.py
import bpy
bl_info = {
"name": "Add-ons to test",
"author": "Nutti",
"version": (1, 0),
"blender": (2, 75, 0),
"location": "UV Mapping >Add-ons to test",
"description": "Add-ons to test",
"warning": "",
"support": "TESTING",
"wiki_url": "",
"tracker_url": "",
"category": "UV"
}
class TestOps(bpy.types.Operator):
bl_idname = "uv.test_ops"
bl_label = "test"
bl_description = "Operation to test"
bl_options = {'REGISTER', 'UNDO'}
def execute(self, context):
return {'FINISHED'}
def register():
bpy.utils.register_module(__name__)
def unregister():
bpy.utils.unregister_module(__name__)
if __name__ == "__main__":
register()
Then save the configuration file for Travis CI as `` `.travis.yml```.
.travis.A commentary on yml can be found in the comments.
Basically, you can understand it from the contents of the comment, but if you have trouble writing ``` .travis.yml```, the following article will be helpful.
* [[Travis CI] This and that written in travis.yml](http://qiita.com/oh_rusty_nail/items/157241b6cb5a304462fe)
#### **`yaml:.travis.yml`**
#Programming language specification #Blender add-on is written in Python, so specify python language: python
#Python version to use #★ You can identify the version of Python used from Blender's Python console python:
#What to do before install before_install: #Install the latest Blender possible #Installing via a package manager will automatically install Blender-dependent packages (because manually installing dependent packages can be tedious)
#Preparation for test execution install: #Create and move workspaces
#Test run script: python ${PWD}/run_tests.py ${PWD}/tmp/blender/blender
# Creating a test script
#### **`.travis.The command written in the yml script is executed to start the test.`**
Create a test script `` `run_tests.py``` to be executed. This will be the original test script that calls the individual tests. The test script is written in Python, the development language for Blender add-ons.
The point is to run Blender on the command line to eliminate the UI display. You can check the options that can be specified when running Blender from the command line from the following site.
http://wiki.blender.org/index.php/Doc:JA/2.6/Manual/Render/Command_Line
run_tests.py
import sys
import subprocess
if len(sys.argv) != 2:
exit(-1)
blender_path = sys.argv[1] #Blender body path
addon_name = 'test_addon' #Add-ons to test
blend_file = 'test_1.blend' #Created for testing.blend file
src_file = 'test_1.py' #Individual test script
#Individual test script (test_1.py) run
#Command to be executed: blender--addons test_addon --factory-startup -noaudio -b test_1.blend --python test_1.py
#option:
# --addons: test_Enable addon
# --factory-startup: startup.Do not read blend files
# -noaudio:Disable sound
# -b:Start Blender without UI
# blend_file:Read.blend file
# --python: src_Execute the Python script specified in file
subprocess.call([blender_path, '--addons', addon_name, '--factory-startup', '-noaudio', '-b', blend_file, '--python', src_file])
Then create a separate test script test_1.py
called from
run_tests.py```.
There are many ways to test, but the unittest module, Python's testing framework, is the quickest way to go.
http://docs.python.jp/2/library/unittest.html
test_1.py
import unittest #Python test framework
import bpy
#Test set
class TestAddon(unittest.TestCase):
#Confirm that the add-on has been successfully activated
def test_addon_enabled(self):
self.assertIsNotNone(by.ops.uv.test_ops)
#Execute the add-on and confirm that it ended normally
def test_execute(self):
result = boy.ops.uv.test_ops()
self.assertSetEqual(result, {'FINISHED'})
#Creating a test set
suite = unittest.defaultTestLoader.loadTestsFromTestCase(TestAddon)
#Test run
unittest.TextTestRunner().run(suite)
Finally, let's save the .blend file as `` `test_1.blend``` with Blender running.
test_1.blend is used when executing the test.This is a blend file.
If you want to actually test it, you need to create a .blend file for the test you want to run.
This time, for the sake of simplicity, I saved the state when Blender started.
# Run the test
The test will be executed automatically by `` `push``` to the repository you tested.
#### **`run_test.sh`**
```sh
$ git push
Let's check the test execution result from the Travis CI site. If the test is successful, you should see the screen below.
You can also check the details of the contents at the time of test execution on the Web, and you can see that the process described in .travis.yml
is being executed.
This time, we are running two tests, test_addon_enabled
and
test_execute, so it is displayed as` `Ran 2 tests in 0.001s
.
After that, OK
indicating that the test passed is output, so you can see that the test passed successfully.
Testing is done every time you push to the repository, eliminating the need to manually check if the add-on is updated. You can avoid the hassle of testing and manual confirmation mistakes, and add-on developers can concentrate on development, so let's automate the parts that can be automated more and more.
Recommended Posts