@Mike Sahm, that is a good question. As Larry mentioned, you can test your measures using the Apply measure now. I typically test measures via RubyMine while I write them, and then do additional testing with the Apply measure now. There are a number of nice things about testing outside of the GUI.

1. You can automate testing so you can batch run when new versions of OpenStudio come out
2. You can run multiple input and source model combinations, for example seeing that the measures fails gracefully if the user provides bad input such as a negative value for a multiplier.
3. You can sanity check not just that the measure run, but you can inspect the resulting model and confirm that the values were changed as you expected.

I write my test in parallel with my measure. If you make a new measure in the OpenStudio GUI it comes with a working test. I would first update the arguments in the measure to be what I want, strip out all of the run section between the "Initial Condition" and "Final Condition" and would try to update the test to pass. Then I would start to fill out the run section of the measure, and just test every time I add a new section. I don't have to stop what I'm doing, it is just a click to run. Some screenshots and additional configuration details are below.

This is a screenshot of a new measure opened in Ruby Mine. Notice how there is a "tests" folder next to measure.rb. I have the new_measure_test.rb file open in the right. That is what I run to test the measure. I don't call the measure directly. This will pass it a model (or in this case make a new model) along with the user argument values.

Under the run menu you can edit and create configuration. This shows my configuration. The only one I change for each test is the "Ruby script" which points the specific test file I'm running. The other values help it to find OpenStudio and Ruby. You can setup various ruby versions under "File/Settings/Ruby SDK and Gems". The screenshot above is setup to use my developer build of OpenStudio, but it is perfectly fine to use this workflow with an installed version of OpenStudio. In other words, any user can write and test ruby scripts without having to compile the software.

Here is what the "Ruby arguments" would look like for an installed version of OpenStudio.

-e $stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift) -I 'C:\Program Files (x86)\OpenStudio 1.5.0\Ruby'

@Mike Sahm, that is a good question. As Larry mentioned, you can test your measures using the Apply measure now. now features. I typically test measures via RubyMine while I write them, and then do additional testing with the Apply measure now. There are a number of nice things about testing outside of the GUI.

1. You can automate testing so you can batch run when new versions of OpenStudio come out
2. You can run multiple input and source model combinations, for example seeing that the measures fails gracefully if the user provides bad input such as a negative value for a multiplier.
3. You can sanity check not just that the measure run, but you can inspect the resulting model and confirm that the values were changed as you expected.

I write my test in parallel with my measure. If you make a new measure in the OpenStudio GUI it comes with a working test. I would first update the arguments in the measure to be what I want, strip out all of the run section between the "Initial Condition" and "Final Condition" and would try to update the test to pass. Then I would start to fill out the run section of the measure, and just test every time I add a new section. I don't have to stop what I'm doing, it is just a click to run. Some screenshots and additional configuration details are below.

This is a screenshot of a new measure opened in Ruby Mine. Notice how there is a "tests" folder next to measure.rb. I have the new_measure_test.rb file open in the right. That is what I run to test the measure. I don't call the measure directly. This will pass it a model (or in this case make a new model) along with the user argument values.

Under the run menu you can edit and create configuration. This shows my configuration. The only one I change for each test is the "Ruby script" which points the specific test file I'm running. The other values help it to find OpenStudio and Ruby. You can setup various ruby versions under "File/Settings/Ruby SDK and Gems". The screenshot above is setup to use my developer build of OpenStudio, but it is perfectly fine to use this workflow with an installed version of OpenStudio. In other words, any user can write and test ruby scripts without having to compile the software.

Here is what the "Ruby arguments" would look like for an installed version of OpenStudio.

-e $stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift) -I 'C:\Program Files (x86)\OpenStudio 1.5.0\Ruby'

@Mike Sahm, that is a good question. As Larry mentioned, you can test your measures using the Apply measure now features. I typically test measures via RubyMine while I write them, and then do additional testing with the Apply measure now. There are a number of nice things about testing outside of the GUI.

1. You can automate testing so you can batch run when new versions of OpenStudio come out
2. You can run multiple input and source model combinations, for example seeing that the measures fails gracefully if the user provides bad input such as a negative value for a multiplier.
3. You can sanity check not just that the measure run, but you can inspect the resulting model and confirm that the values were changed as you expected.

I write my test in parallel with my measure. If you make a new measure in the OpenStudio GUI it comes with a working test. I would first update the arguments in the measure to be what I want, strip out all of the run section between the "Initial Condition" and "Final Condition" and would try to update the test to pass. Then I would start to fill out the run section of the measure, and just test every time I add a new section. I don't have to stop what I'm doing, it is just a click to run. Some screenshots and additional configuration details are below.

This is a screenshot of a new measure opened in Ruby Mine. Notice how there is a "tests" folder next to measure.rb. I have the new_measure_test.rb file open in the right. That is what I run to test the measure. I don't call the measure directly. This will pass it a model (or in this case make a new model) along with the user argument values.

Under the run menu you can edit and create configuration. This shows my configuration. The only one I change for each test is the "Ruby script" which points the specific test file I'm running. The other values help it to find OpenStudio and Ruby. You can setup various ruby versions under "File/Settings/Ruby SDK and Gems". The screenshot above is setup to use my developer build of OpenStudio, but it is perfectly fine to use this workflow with an installed version of OpenStudio. In other words, any user can write and test ruby scripts without having to compile the software.

Here is what the "Ruby arguments" would look like for an installed version of OpenStudio.

-e $stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift) -I 'C:\Program Files (x86)\OpenStudio 1.5.0\Ruby'

# make an empty model
model = OpenStudio::Model::Model.new

# load the test model
translator = OpenStudio::OSVersion::VersionTranslator.new
path = OpenStudio::Path.new(File.dirname(__FILE__) + "/ImportedIdf_RefFsr.osm")
model = translator.loadModel(path)
assert((not model.empty?))
model = model.get

@Mike Sahm, that is a good question. As Larry mentioned, you can test your measures using the Apply measure now features. I typically test measures via RubyMine while I write them, and then do additional testing with the Apply measure now. There are a number of nice things about testing outside of the GUI.

1. You can automate testing so you can batch run when new versions of OpenStudio come out
2. You can run multiple input and source model combinations, for example seeing that the measures fails gracefully if the user provides bad input such as a negative value for a multiplier.
3. You can sanity check not just that the measure run, but you can inspect the resulting model and confirm that the values were changed as you expected.

I write my test in parallel with my measure. If you make a new measure in the OpenStudio GUI it comes with a working test. I would first update the arguments in the measure to be what I want, strip out all of the run section between the "Initial Condition" and "Final Condition" and would try to update the test to pass. Then I would start to fill out the run section of the measure, and just test every time I add a new section. I don't have to stop what I'm doing, it is just a click to run. Some screenshots and additional configuration details are below.

This is a screenshot of a new measure opened in Ruby Mine. Notice how there is a "tests" folder next to measure.rb. I have the new_measure_test.rb file open in the right. That is what I run to test the measure. I don't call the measure directly. This will pass it a model (or in this case make a new model) along with the user argument values.

Under the run menu you can edit and create configuration. This shows my configuration. The only one I change for each test is the "Ruby script" which points the specific test file I'm running. The other values help it to find OpenStudio and Ruby. You can setup various ruby versions under "File/Settings/Ruby SDK and Gems". The screenshot above is setup to use my developer build of OpenStudio, but it is perfectly fine to use this workflow with an installed version of OpenStudio. In other words, any user can write and test ruby scripts without having to compile the software.

Here is what the "Ruby arguments" would look like for an installed version of OpenStudio.

-e $stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift) -I 'C:\Program Files (x86)\OpenStudio 1.5.0\Ruby'

There are a few other things I always do that are not in the default new measure test.

1. I add the "show_output(result). This shows all the info, warning and initial/final condition messages that you woudl see in the GUI.

2. I like to add code in to save the model. This can be commented out when not needed, but it is good to dig around in the resulting model to really see if it did what you wanted.

   # run the measure measure.run(model, runner, argument_map) result = runner.result show_output(result) assert(result.value.valueName == "Success")

   save the model

   output_dir = File.expand_path('output', File.dirname(__FILE__)) FileUtils.mkdir output_dir unless Dir.exist? output_dir output_file_path = OpenStudio::Path.new("#{output_dir}/test_imported_idf_model_results.osm") model.save(output_file_path,true)

Also, in our test we made a new empty model, but many times if the measure is altering a fan, it might be nice to have a model already ready vs. making an empty one. Here is what that code looks like in the test.

This is what is in by default

# make an empty model
model = OpenStudio::Model::Model.new

This adds an existing model. That model should live in the same test directory.

# load the test model
translator = OpenStudio::OSVersion::VersionTranslator.new
path = OpenStudio::Path.new(File.dirname(__FILE__) + "/ImportedIdf_RefFsr.osm")
"/MyTestInputModel.osm")
model = translator.loadModel(path)
assert((not model.empty?))
model = model.get

@Mike Sahm, that is a good question. As Larry mentioned, you can test your measures using the Apply measure now features. I typically test measures via RubyMine while I write them, and then do additional testing with the Apply measure now. There are a number of nice things about testing outside of the GUI.

1. You can automate testing so you can batch run when new versions of OpenStudio come out
2. You can run multiple input and source model combinations, for example seeing that the measures fails gracefully if the user provides bad input such as a negative value for a multiplier.
3. You can sanity check not just that the measure run, but you can inspect the resulting model and confirm that the values were changed as you expected.

I write my test in parallel with my measure. If you make a new measure in the OpenStudio GUI it comes with a working test. I would first update the arguments in the measure to be what I want, strip out all of the run section between the "Initial Condition" and "Final Condition" and would try to then I update the test to pass. until it passes. Then I would start to fill out the run section of the measure, and just test every time I add a new section. I don't have to stop what I'm doing, it is just a click to run. Some screenshots and additional configuration details are below.

This is a screenshot of a new measure opened in Ruby Mine. Notice how there is a "tests" folder next to measure.rb. I have the new_measure_test.rb file open in the right. That is what I run to test the measure. I don't call the measure directly. This will pass it a model (or in this case make a new model) along with the user argument values.

Under the run menu you can edit and create configuration. This shows my configuration. The only one I change for each test is the "Ruby script" which points the specific test file I'm running. The other values help it to find OpenStudio and Ruby. You can setup various ruby versions under "File/Settings/Ruby SDK and Gems". The screenshot above is setup to use my developer build of OpenStudio, but it is perfectly fine to use this workflow with an installed version of OpenStudio. In other words, any user can write and test ruby scripts without having to compile the software.

Here is what the "Ruby arguments" would look like for an installed version of OpenStudio.

-e $stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift) -I 'C:\Program Files (x86)\OpenStudio 1.5.0\Ruby'

There are a few other things I always do that are not in the default new measure test.

1. I add the "show_output(result). "show_output(result)". This shows all the info, warning and initial/final condition messages that you woudl see in the GUI.

2. I I also like to add code in to save the model. This can be commented out when not needed, but it is good to dig around in the resulting model to really see if it did what you wanted.

-

# run the measure
measure.run(model, runner, argument_map)
result = runner.result
show_output(result)
assert(result.value.valueName == "Success")
 
"Success")

# save the model
 
model
output_dir = File.expand_path('output', File.dirname(__FILE__))
FileUtils.mkdir output_dir unless Dir.exist? output_dir
output_file_path = OpenStudio::Path.new("#{output_dir}/test_imported_idf_model_results.osm")
model.save(output_file_path,true)
 model.save(output_file_path,true)

Also, in our test we made a new empty model, but many times if the measure is altering a fan, it might be nice to have a model already ready vs. making an empty one. Here is what that code looks like in the test.

This is what is in by default

# make an empty model
model = OpenStudio::Model::Model.new

This adds an existing model. That model should live in the same test directory.

# load the test model
translator = OpenStudio::OSVersion::VersionTranslator.new
path = OpenStudio::Path.new(File.dirname(__FILE__) + "/MyTestInputModel.osm")
model = translator.loadModel(path)
assert((not model.empty?))
model = model.get

@Mike Sahm, that is a good question. As Larry mentioned, you can test your measures using the Apply measure now features. I typically test measures via RubyMine while I write them, and then do additional testing with the Apply measure now. There are a number of nice things about testing outside of the GUI.

1. You can automate testing so you can batch run when new versions of OpenStudio come out
2. You can run multiple input and source model combinations, for example seeing that the measures fails gracefully if the user provides bad input such as a negative value for a multiplier.
3. You can sanity check not just that the measure run, but you can inspect the resulting model and confirm that the values were changed as you expected.
4. For reporting measure you can save the SQL output so you can cycle very quickly without having to re-run EnergyPlus.

I write my test in parallel with my measure. If you make a new measure in the OpenStudio GUI it comes with a working test. I first update the arguments in the measure to be what I want, strip out all of the run section between the "Initial Condition" and "Final Condition" and then I update the test until it passes. Then I start to fill out the run section of the measure, and just test every time I add a new section. I don't have to stop what I'm doing, it is just a click to run. Some screenshots and additional configuration details are below.

This is a screenshot of a new measure opened in Ruby Mine. Notice how there is a "tests" folder next to measure.rb. I have the new_measure_test.rb file open in the right. That is what I run to test the measure. I don't call the measure directly. This will pass it a model (or in this case make a new model) along with the user argument values.

Under the run menu you can edit and create configuration. This shows my configuration. The only one I change for each test is the "Ruby script" which points the specific test file I'm running. The other values help it to find OpenStudio and Ruby. You can setup various ruby versions under "File/Settings/Ruby SDK and Gems". The screenshot above is setup to use my developer build of OpenStudio, but it is perfectly fine to use this workflow with an installed version of OpenStudio. In other words, any user can write and test ruby scripts without having to compile the software.

Here is what the "Ruby arguments" would look like for an installed version of OpenStudio.

-e $stdout.sync=true;$stderr.sync=true;load($0=ARGV.shift) -I 'C:\Program Files (x86)\OpenStudio 1.5.0\Ruby'

There are a few other things I always do that are not in the default new measure test.

1. I add "show_output(result)". This shows all the info, warning and initial/final condition messages that you woudl see in the GUI.
2. I also like to add code in to save the model. This can be commented out when not needed, but it is good to dig around in the resulting model to really see if it did what you wanted.

-

# run the measure
measure.run(model, runner, argument_map)
result = runner.result
show_output(result)
assert(result.value.valueName == "Success")

# save the model
output_dir = File.expand_path('output', File.dirname(__FILE__))
FileUtils.mkdir output_dir unless Dir.exist? output_dir
output_file_path = OpenStudio::Path.new("#{output_dir}/test_imported_idf_model_results.osm")
model.save(output_file_path,true)

Also, in our test we made a new empty model, but many times if the measure is altering a fan, it might be nice to have a model already ready vs. making an empty one. Here is what that code looks like in the test.

This is what is in by default

# make an empty model
model = OpenStudio::Model::Model.new

This adds an existing model. That model should live in the same test directory.

# load the test model
translator = OpenStudio::OSVersion::VersionTranslator.new
path = OpenStudio::Path.new(File.dirname(__FILE__) + "/MyTestInputModel.osm")
model = translator.loadModel(path)
assert((not model.empty?))
model = model.get