One of the features of JEST is snapshot testing. This feature is mainly useful for testing UI components in a headless environment to ensure the stability of the generated markup. So, any changes to the markup are caught by the test cases which then need to be carefully reviewed and resolved. This works by JEST keeping track of the prior generated markup as a snapshot and comparing it with subsequent runs.
One of the key features of SQL Frames is its ability to auto generate SQL. While generating code against multiple target databases is lot easier than parsing multiple flavors of SQL, it is still a complex piece of logic especially when there is no single place to look at all the possible ways of writing SQL, even the standard SQL. As a result, there were a lot of attempts to get this right with trail and error and in the process fixing one part used to regress the other. After some frustration of repeated regressions, I got the idea of using snapshot testing for SQL. Yes, why not just snapshot the generated SQL and every time there is a change to the SQL generation engine, running the tests would catch any regression. After implementing this strategy, the quality of this part of the code has increased and gave the comfort of not breaking things as more SQL clauses were added to the generation engine.
Integrating JEST into the workflow has been easy. In addition, it has support for code coverage. SQL Frames currently has above 60% coverage. Even though the overall code coverage is slightly above 60%, the backend part of the code related to the analytics engine and SQL generation has lot more coverage. The place that is lagging is the code that generates the UI and charts. The eventual goal is to increase code coverage for this part of the code as well and get to more than 80%.