"Our test suite passed," the developer announced. The business analyst looked at the console output - pages of cryptic assertions, stack traces, and technical jargon. "Great," she replied. "But what did it actually test?" The developer scrolled through the logs, searching for something human-readable. Nothing.
We've all seen it happen. The developers on the team excitedly discuss the latest framework they're implementing, while the test automation engineers quietly stick to the same Selenium scripts they've been maintaining for years. It's a strange disconnect – the very people who should be at the forefront of technological validation often trail behind when it comes to evolving their own toolset.
Have you ever been in one piece of code and need to alert an unlinked piece of code to what is going on? This is sometimes very tricky to solve. Enter Flag Monkey
Within any Guidewire environment that runs more than one xCenter, there are a few ways to achieve this. For many this includes running multiple Studios. There are better, more streamlined ways to work which will save time while starting, debugging, and running your apps.
Query.make() is the heart of all database queries. Queries are made against entities (e.g. .eti, .etx) which are complex database objects. xCenter uses an Object Relational Mapper (ORM) to retrieve and save all data from the Database Management System (DBMS). By using an ORM, the query logic remains DBMS agnostic, so it does not matter if we are using MS SQL, Oracle, DB2 or H2, the query language is abstracted away from us. Most of the SQL produced by the ORM is ANSI SQL with some exceptions for specific DBMS implementations.
Guidewire test automation,
