Thank you JEST

Building an enterprise grade software requires high level of quality assurance. For quality to increase, it first needs to be measured. In the very early stages of SQL Frames development, the focus was just building and more building of features with a few random code snippets thrown here and there to occasionally make sure nothing is broken. But as the project moved past the simple viable idea to a real project, there was a need to uphold the quality as even more features were being added. After carefully searching for testing frameworks for JavaScript, I have decided to go with JEST.

As I mentioned earlier, SQL Frames moved from pure JavaScript to 100% TypeScript based project. So, one of the requirements when selecting a test framework was that it plays well with TypeScript. Another requirement was that, while SQL Frames is meant to be directly executed within the browser, it also supported executing entirely within Node. Hence, the test framework should be able to support execution in a Node environment. SQL Frames has both backend code (although all of it gets executed within the browser) and frontend UI code. So, the test framework should support the ability to do headless testing for UI. And JEST fit the bill for all these requirements.

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%.