Difference between revisions of "MicroMVDs for exchange requirements"

From Wiki.OSArch
(Created page with "To guarantee the consistent and correct delivery of BIM data, based on the agreed exchange requirements, unit tests will be written to check that data is entered, appropriatel...")
 
Line 1: Line 1:
To guarantee the consistent and correct delivery of BIM data, based on the agreed exchange requirements, unit tests will be written to check that data is entered, appropriately formatted, and that important semantic relationships between BIM entities exist. '''A test is a single sentence that a computer can use to automatically validate data.'''
+
To guarantee the consistent and correct delivery of BIM data, exchange requirements and quality checks can be converted into computer-automated tests to check that data is entered, appropriately formatted, and that important semantic relationships between BIM entities exist. '''A test is a single sentence that a computer can use to automatically validate data.'''
  
For example, if an exchange requirement is to provide an IFC4 file, an example of a unit test would be <code>the file should be an IFC4 file</code>. An automated test running system will read this sentence, and verify that the requirement has been met. A HTML report will be automatically generated for stakeholders to review. The exact details of how the test runner interprets the test sentence would be defined using the ''Python'' programming language. The definition would be usually under 20 lines of code and simple to understand, to prevent ambiguity.
+
For example, if an exchange requirement is to provide an IFC4 file, it may be written as <code>the file should be an IFC4 file</code>. An automated test running system will read this sentence, and verify that the requirement has been met. This automated test can be run on Windows, Mac, Linux, or any BIM server. A report will be automatically generated for stakeholders to review.
  
Related test sentences to a single exchange requirement are called a ''MicroMVD''. Example MicroMVDs include ''Model setup and geolocation'', and ''COBie asset management data''. The test author will define which sentences are part of the MicroMVD, so the recipient will be aware of what will be audited.
+
Three things are required to apply this testing workflow:
 +
 
 +
* BIM data in OpenBIM format, usually supplied by a BIM author
 +
* A list of exchange requirement tests, taken from the [[List of MicroMVDs]], or custom-built by a software developer
 +
* A test execution program, such as [https://blenderbim.org/download.html BIMTester]
 +
 
 +
Unlike other testing solutions like Solibri, MicroMVDs are non-proprietary, do not expire, are free, much lighter, are easy to change and develop, and are cross-platform.
  
 
== Authoring test suites ==
 
== Authoring test suites ==
Line 17: Line 23:
  
 
     Scenario: Check for model setup
 
     Scenario: Check for model setup
        Given that an IFC file is loaded
 
 
         Then there is a building named "My Building"
 
         Then there is a building named "My Building"
 
         Then the project should have geolocation data
 
         Then the project should have geolocation data
  
 
     Scenario: Check for correct IFC classifications
 
     Scenario: Check for correct IFC classifications
        Given that an IFC file is loaded
 
 
         Then the element 3p_TRXKdzF2wWH87Oi_za1 is an IfcSlab
 
         Then the element 3p_TRXKdzF2wWH87Oi_za1 is an IfcSlab
 
         Then the element 02Z83vdEbAgfTHGQKEXMFV is an IfcFurniture
 
         Then the element 02Z83vdEbAgfTHGQKEXMFV is an IfcFurniture

Revision as of 00:04, 18 March 2020

To guarantee the consistent and correct delivery of BIM data, exchange requirements and quality checks can be converted into computer-automated tests to check that data is entered, appropriately formatted, and that important semantic relationships between BIM entities exist. A test is a single sentence that a computer can use to automatically validate data.

For example, if an exchange requirement is to provide an IFC4 file, it may be written as the file should be an IFC4 file. An automated test running system will read this sentence, and verify that the requirement has been met. This automated test can be run on Windows, Mac, Linux, or any BIM server. A report will be automatically generated for stakeholders to review.

Three things are required to apply this testing workflow:

  • BIM data in OpenBIM format, usually supplied by a BIM author
  • A list of exchange requirement tests, taken from the List of MicroMVDs, or custom-built by a software developer
  • A test execution program, such as BIMTester

Unlike other testing solutions like Solibri, MicroMVDs are non-proprietary, do not expire, are free, much lighter, are easy to change and develop, and are cross-platform.

Authoring test suites

Each test suite is composed of one or more plain text files, given the file extension of .feature. It can be edited in any text editor, such as Vim, Apple TextEdit, or Microsoft Notepad. The file name is arbitrary, but may be used to describe what it is testing.

An example of the content of a single *.feature file is shown below. Each *.feature file represents a test suite and must follow the format below.

Feature: BIM minimum requirements
    Scenario: Check we have received an IFC file
        Given the IFC file "project.ifc"
        Then the file should be an IFC2X3 file

    Scenario: Check for model setup
        Then there is a building named "My Building"
        Then the project should have geolocation data

    Scenario: Check for correct IFC classifications
        Then the element 3p_TRXKdzF2wWH87Oi_za1 is an IfcSlab
        Then the element 02Z83vdEbAgfTHGQKEXMFV is an IfcFurniture
        Then the element 3zR58KMpzF49WT78FdAdPh is an IfcWall

A feature file always starts by defining the name of the Feature, in this case BIM minimum requirements. It is then followed by one or more Scenario blocks. Each scenario has a name that focuses on a particular exchange requirement, and contains one or more test sentences. Each sentence checks data related to the scenario. The feature name and scenario names can be anything, but must be prefixed by Feature: and Scenario: respectively. The test sentences within each Scenario block must match a pattern defined in the MicroMVD for the project, and must be prefixed with Given , When , or Then .

Packaging test suites for recipients

The author of the test suite will provide a folder named features/. The contents of this folder will contain:

features/test-suite-A.feature # This is a test suite
features/test-suite-B.feature # This is another test suite, you can have multiple
features/environment.py # This defines the test environment
features/template.html # This is the HTML report template
features/steps/steps.py # The defines the test sentences

These files constitute the full test system, and must be shared in full to all recipients and all authors. This ensures full transparency of exchange requirements.

The steps.py file requires basic programming knowledge to understand and modify, and is generally only modified by the test author. Recipients are free to inspect it to gain a better understanding of what constitutes test compliance.

The environment.py file contains the environment settings to run the tests, using the Behave system. An intermediate knowledge of Behave and Python is required to modify this file. For most recipients, this file must be left alone.

The template.html file contains a HTML report template. It is plain HTML code with Mustache for the templating language. A basic knowledge of HTML and Mustache is required to modify this file, which is self-explanatory.

Receiving and running test suites

A recipient will receive a features/ directory. They are not required to modify the files in any way.

The cross-platform, free software BIMTester tool is capable of running the test suite and generating reports. The BIMTester tool expects the features/ directory to be in the current working directory.

Recipients are encouraged to run the tests and generate reports at their convenience. The test author may optionally provide an automated platform which runs tests and generate downloadable reports, as well as track progress on test results.

Maintaining test suites

The test suite will be working document that will grow throughout the project lifecycle to ensure that data quality regressions are not made, and that the level of information which has been audited is clearly documented.

The test author will advise all recipients whenever new tests are being introduced or new test sentences are being defined.