@Syres916 thanks! I've edited it, could you check again? The first time I'm opening the settings are unchecked. Is there a workaround or is it just with the manual builds?

The easy way I check whether a UI file is correct is by opening it with Qt Designer and it looks fine to me. You are loading FreeCAD with none existent config files (I don't know whether these Booleans are held in Pref Packs?

Also you'll have to speak nicely to @FEA-eng and @oliveroxtoby as this appears to break at least one of their tests in FEM (test_box_static) and CfdOF (test_run - TestCfdOF.DamBreak3DTest) workbenches due to the edge numbers changing I would guess.

thanks for noticing.
@FEA-eng / @oliveroxtoby / @marioalexis84 is this change OK for those tests or other implementations and could these tests be changed?

All good with me. Happy to fix up my one. Thank you! @Syres916 @maxwxyz

test_box_static

https://github.com/FreeCAD/FreeCAD/blob/958d83ed06ca32294227b4e1270cf41c838962e5/src/Mod/Fem/femexamples/boxanalysis_static.py

This example is literally just a Box (Part Box primitive). Strange that refine makes a difference here. But maybe adding a line setting refine to true for this part will be sufficient. I would be more worried about some FEM Examples with less basic geometry. Some time ago I fixed a similar issue where Make Face not set to true by default made several Elmer 2D examples fail: #12646 and #12777.

@oliveroxtoby @FEA-eng great. Do I need to fix/change the tests in my PR (if so, how?) or do you change them?

@oliveroxtoby @FEA-eng great. Do I need to fix/change the tests in my PR (if so, how?) or do you change them?

Not for CfdOF, as it's an external module.

There seems to be some interference with TNP stuff (at least according to the failing checks). Maybe that's also what causes the failure of that FEM test. Anyway, the failing checks here should be resolved first and then we'll see.

@maxwxyz could you rebase the branch to test it?

@marioalexis84 done

@marioalexis84 still struggling with the FEM tests

@maxwxyz I'm not getting any errors in the fem unit test even with three boxes checked.

@bgbsww I get two test failures in CI:

======================================================================
FAIL: testRemovedExternalGeometryReference (SketcherTests.TestSketcherSolver.TestSketcherSolver.testRemovedExternalGeometryReference)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/runner/work/FreeCAD/FreeCAD/.conda/freecad/opt/freecad/Mod/Sketcher/SketcherTests/TestSketcherSolver.py", line 522, in testRemovedExternalGeometryReference
    self.assertEqual(len(hole.Shape.Edges), 13)
AssertionError: 12 != 13

======================================================================
FAIL: testPartDesignTNPFillet (PartDesignTests.TestTopologicalNamingProblem.TestTopologicalNamingProblem.testPartDesignTNPFillet)
Test Fillet
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/runner/work/FreeCAD/FreeCAD/.conda/freecad/opt/freecad/Mod/PartDesign/PartDesignTests/TestTopologicalNamingProblem.py", line 1431, in testPartDesignTNPFillet
    self.assertEqual(body.Shape.childShapes()[0].ElementMapSize, 62)
AssertionError: 64 != 62

Interesting. It isn't unreasonable to change ElementMapSize tests, because sometimes the fix is changing how a shape is created and that affects the element map. So the fillet test might just need adjusting.

The removed external geometry issue, however might be pointing at an introduced bug. Looking ...

... By changing the refine setting, you are slightly tweaking the produced shapes, and that is changing what both of these tests expect. You should tweak the tests to match the result values - you aren't breaking anything with this.

@maxwxyz sorry for the long delay, I was deep in another bug.

No worries, just let me know if these tests should be fixed within this PR or in a separate (and how I could fix them).

Will merge after the CI failure is resolved.

@maxwxyz you should fix them in this PR, by changing the expected assertions in the tests to match above: the 13 to a 12 and the 62 to a 64. Of course we want to understand changes to tests before making them, but in this specific case they are explained by the refine being on.

@bgbsww thanks, updated. let's see...

edit: seems not to work

Dropping this to Draft while you keep working.

@bgbsww changing the tests to the values did not change the CI tests here. What else do I need to do to fix this?

Based on looking at a couple of the fails ( going down the details), it looks like that 64 should have stayed a 62. Since the difference between those is a refine, I wonder if something is a little different between your local test environment and the CI builds. In any case, step one is to take that change back out, and then if the CI still fails, look to see what the problem is.

@chennes all tests should've been fixed now.

This PR reveals the weakness of several unit tests. On many users' systems the refine settings are still switched off and this makes some tests to fail now.

Correctly working unit tests must be independent of user settings as otherwise they are useless.