Lexpedite / blawx

A user-friendly web-based tool for Rules as Code.
MIT License
101 stars 9 forks source link

getSectionReferences() fails when there are two section references in one line of code #562

Closed foxcoleman closed 1 year ago

foxcoleman commented 1 year ago
  1. My 3_1 test doesn't work, yet everything else seems to be working fine. I think this may be due to a change I made to one of my category titles (minor_works -->minor_work), which lead me to make a ton of block replacements.
  2. When I run my pre-filled everything_test in the Scenario Editor, the very top of my answer makes an assumption that "A is not construction" when construction was fed to it as a fact and is an important component for the conclusion. Why is it doing that?
  3. Did I build the numbered test correctly - is the goal here to do unit testing? Do I need to do some form of integration testing as well, or is that basically being done with the Scenario Editor / API Endpoint tests?

MinorWorksOrder.txt

Gauntlet173 commented 1 year ago

On 3:

The words "unit" test and "integration" test are difficult to apply to writing Blawx code in any consistent way.

"Correctly" is also not something I have a definition for.

My habit, when the code is complicated, is to imagine the sections as a dependency tree, where some depend on the conclusions of others, and others depend only on the user inputs. I start with the user input sections (the leaves of the tree), and test those first. Often, I will make the inputs abducible, and make a general query of both the positive and negated result, to find all the circumstances in which the reasoner thinks the conclusion does and does not hold. When I'm satisfied the leaves work, I test the sections that depend on them, and so on, until everything works. When you are dealing with rules that depend on the results of other rules, you could make the inputs to those rules abducible directly, or set facts for them directly (which is kind of like unit testing the rule), and/or you can make the inputs to the rules they depend on abducible, or set those facts explicitly (which is kind of like integration testing). Note that the larger the the scope of abducible inputs you use in a Blawx test the longer the processing time, and you may reach a point where the server can't find an answer before it times out. I would test both ways to the degree feasible before giving it to the subject matter expert to validate. But that's not necessarily always the way to do it. It depends on a lot of factors.

foxcoleman commented 1 year ago

MinorWorksOrder.txt

Gauntlet173 commented 1 year ago

On 2, "A" is a hypothetical object that was created in the course of the reasoning. What it is reporting is not an assumption, but a constraint. A was used to represent some object that is not "removal". Usually, it would not be displayed, because the object A does not actually appear anywhere in the explanation. However, there seems to be a capital A used in the text for one of your predicates, so Blawx thought that referred to the variable A, and included the constraint because it thought it was relevant. For now, the solution there would be to not use capital letter A in the text for categories, attributes, and relationships.

Gauntlet173 commented 1 year ago

1 is a bug caused by the way that section references are extracted in the getSectionReferences() function in buttons.js. It wasn't anticipated that there would be two section references in the same statement, so we need to change that function to find only the first.

Also, you have two questions in that test, and only one will work. It can be difficult to predict which will actually run. The recommendation is to have only one question block per test, for now. I'll rename the issue and add it to the bug list.

Gauntlet173 commented 1 year ago

resolved in 1.6.19-alpha