On Mon, 2 Mar 2026 23:00:24 GMT, Andy Goryachev <[email protected]> wrote:
> `AsciiArtParser` seems like a fun toot: the main benefit of using it is that > it requires a graphical representation of the desired outcome, which might be > nice. > > This benefit is also a drawback: these diagrams are difficult to create and > maintain. Plus, we would need to maintain the parser itself as a part of > javafx code base. The parser is purposely very simplistic and unoptimized, as it is only need serve its purpose of verifying layout. I don't expect it to need much maintenance (it's been this way for a few years already). The diagrams are IMHO quite easy to make, and visually show you exactly where components are and how they relate to each other. What was before a jumble of numbers, often incomplete, and hard to grasp (and different every time in FX layout tests) is now a simple visual diagram where things like sums and positions are always tested fully with clear error messages when they deviate. > One possible alternative is to forgo the graphical aspect of it and simply > describe the expected layout in form of a CSV-like table (or a github-like > table), for example: > > ``` > Location | WxH | Margins > ---------|--------|-------- > |10 x 5 | > |200 x 5 | 5 5 5 0 > ``` This won't really show you the relation and positions of components, and will quickly become a jumble of numbers just like the standard asserts already are. I specifically wrote this parser a few years ago to test a rather difficult layout container of my own, allowing me to create easy to grasp tests for various complex situations. It's not limited in any way, and can even be used to test nested container layouts to check things like how a VBox behaves nested in an HBox nested in a BorderPane, to ensure even interactions between different containers can be verified. I think it really is a very useful tool in the toolkit, and I think one that will encourage more and better tests for FX controls. ------------- PR Comment: https://git.openjdk.org/jfx/pull/2077#issuecomment-3988944177
