We’ve built an AI-powered BIM validation app - but does it actually work? Before we deploy this to production or scale it up, we need to answer a fundamental question: are we getting the outputs we expect from our inputs? Let’s build confidence in our app through smart testing!
Why Testing Matters (Especially with AI-Generated Code)
Here’s the thing about AI coding assistants: they’re powerful, but they’re not infallible. We used Kiro IDE to generate most of our validation app’s heavy lifting, and while that’s incredibly productive, it means we need to verify the results.
The testing principle is simple:
- Inputs: An IFC file + an IDS specification file
- Expected Outputs: Correct validation results based on the specification
- Goal: Confirm the app validates what we expect it to validate
Creating a Simple Test Case: The Four Walls
Rather than testing with a complex building model, I created the simplest possible scenario using Bonsai BIM (an add-in for Blender):
Four walls. That’s it.
But here’s the clever part - three walls have quantity takeoff properties, and one doesn’t. This gives us a clear, predictable test case:
- Walls 1, 2, 3: Have
Qto_WallBaseQuantitiesproperties (height, length, net side area, etc.) - Wall 4: Missing these properties (intentionally!)
If you select the walls in Bonsai BIM, you can see which ones have quantities and which don’t. This creates a perfect validation scenario - we know exactly what should pass and what should fail.
The IDS File: Defining Our Validation Rules
Our IDS (Information Delivery Specification) file is an XML document that defines two requirements for walls:
- Applicability: Walls must be contained within an
IfcBuildingStorey(i.e., on a level) - Requirements: Walls must have the
Qto_WallBaseQuantitiesproperty set with specific properties:- Height
- Length
- Net side area
- And more…
Pretty straightforward! But before we use this IDS file in our app, we need to validate the IDS file itself.
Smoke Testing: Validating the Validator
Here’s a pro tip that saved me debugging time: validate your IDS file before blaming your code.
buildingSMART International provides a tool called IDS-tool.exe that audits IDS files for validity. Running this smoke test ensures we’re not chasing bugs caused by malformed specifications.
# Run IDS validation (example)
ids-tool.exe validate my-ids-file.xml
When it returns ✓ valid, you know your IDS specification is structurally correct. This eliminates one potential source of bugs before you even start coding.
Validation Round 1: Bonsai BIM
Before testing our custom app, I validated the same IFC + IDS combination in Bonsai BIM itself:
- Open the model in Bonsai BIM (Blender add-in)
- Navigate to Collaborate tab
- Under IFC Tester, load the IDS file from memory
- Execute the validation
- Flag failed entities
Bonsai BIM highlights the failing wall and lists exactly why it failed. This gives us a baseline truth - we know what the correct validation results should be.
Validation Round 2: Our App
Now for the moment of truth. Let’s test the app we built with AI assistance:
- Load the IFC file (our four walls model)
- Load the IDS file (our validation specification)
- Run the validation
- Check the results
Success! ✓
The app correctly identified which walls passed and which failed, matching Bonsai BIM’s results. The validation succeeded, and we can see the detailed results showing:
- Which entities were checked
- Which requirements they met or failed
- Specific details about the failures
What This Test Proves (and Doesn’t)
What We Know Now ✓
- Our inputs are valid (IFC and IDS files are well-formed)
- Our app produces expected outputs for this simple case
- The core validation logic works correctly
- AI-generated code is functioning as intended
What We Don’t Know Yet
- Will this work on full-scale projects with thousands of elements?
- Are there edge cases that break the validation?
- How does performance scale with model size?
I’m fully aware there will likely be bugs when we test this on real-world projects. But that’s okay! The idea here is to build on a solid foundation and iterate over time.
The Testing Philosophy: Start Simple, Iterate Often
This basic validation approach follows a fundamental software development principle:
- Create simple, predictable test cases
- Validate inputs before testing outputs
- Establish baseline truth (using Bonsai BIM as reference)
- Compare app results against baseline
- Iterate and refine as you discover edge cases
By starting with four walls instead of a full building, we can quickly verify core functionality without getting lost in complexity. Pretty neat!
What’s Next?
In the upcoming videos, we’re taking this app to the next level:
- Containerization: Package the app for deployment anywhere
- API Endpoints: Convert the validation logic into a RESTful API
- Flexibility: Enable integration with any other software that can make HTTP requests
Once we containerize this and expose it as an API, we can deploy it anywhere - cloud platforms, on-premises servers, even edge devices. And any software that can make an HTTP request can use our validation service.
Bonus: Interested in Bonsai BIM?
Bonsai BIM is a powerful open-source BIM authoring tool built as a Blender add-in. If you’re interested in learning more about how to create IFC models directly in Blender, drop a comment on YouTube! I’d be happy to create content showing how to use Bonsai BIM for BIM authoring.
Let’s Build Together
Have you built automated validation tools for BIM projects? What testing strategies do you use to validate IFC models? Let me know on YouTube - I’d love to hear about your testing approaches and lessons learned!
Remember: we’re not just building validation tools - we’re learning how to verify that our AI-generated code actually works. And that’s a critical skill in the age of AI-assisted development.
The GitHub repository for this project is available at: https://github.com/vinnividivicci/openingbim-cicd