Testing LookML and Looks

I love that Looker has the ability to perform #testing on the data within the #lookML. Great details documented here: Additionally, I know Looker forces the user to use the LookML validator before committing and deploying updates.

I am trying to figure out a solution to an issue I recently ran into where our lookML was updated with descriptions for fields across multiple views example:

dimension: product_id {

type: number

sql: ${TABLE}.“PRODUCT_ID” ;;

description: “Record ID”

During this update, a source field like ${TABLE}.“PRODUCT_ID” was changed to “PRODUCTID”, thus creating an error in all of the looks that use this field. The LookML validator did not catch this and the user didn’t notice either. As a result, users of the Looks/Dashboards ran into errors for multiple hours. Is there a test I can implement for each Model / View to ensure all Looks that use a Model / View is operating without any errors?

Looking to create a health check of all Looks / Dashboards that have significantly grown over the past year. This would be beneficially for me personally because we are about to roll out Looker to our global team. And as more users have access to our LookML, managing each Model / View / Look / Dashboard will be challenging.

5 replies

The easiest way is to use back-end APIs to validate generated SQL. We implemented a framework to fetch the definition of every explore, dashboard and Look, extract the query (Looker “query” tag) and run it on the server.

If it returns data - everything is fine with SQL. Otherwise it will return an error and you can verify what’s wrong with it.

For explore it is a bit more tricky, you can also get the full definition of every explore via back-end.

then you have to parse it and dynamically construct the query using all columns in the explore. When you fire it off, you will check if SQL is valid when user select all columns.

Userlevel 6

Create a crap look which has every field selected And a nonsense filter on it so you don’t actually scan any data. This will act as a simple sql syntax check against the database. You can schedule this look or hit it via api and just wait for it to fail out.

Userlevel 4

We built an open-source tool called Spectacles to do exactly what you’re describing! [GitHub] [docs]

Spectacles runs SQL queries against your Looker instance using the Looker API to check that each dimension in a project is working as you expect. You can run Spectacles after changes to LookML or after changes to your database.

It’s a lot easier than manually clicking on every field in an explore and it has a bunch of other cool features like running data tests, testing a specific commit, ignoring certain dimensions/explores, and more.

I would love for you to try it out and give us feedback! We have a growing Slack community and we’re working on a cloud-hosted version of the tool for continuous integration and scheduled tests. We’re about 2 weeks away from an alpha launch, so please let me know if you’re interested in trying that out too!

Hello all team,

Thank you all for the subject

In the same subject of LookML test code,  im looking to know if Looker it self can do the test fonction with the same quality of  Spectacles ??.  and can any one confirm if i can intecration auto ci/cd in Looker after the test or i need to use Spectacles for that ??.

I was checking Spectacles and i figured out that it's not open sours and i need to pay to use it, like 350$ / project.

Do not hesitate to participate and enrich the subject and give updates to everyone.



Hi Elyess,

I’m still pretty new to Looker, but I use Content Validator (nearly) every day to check for broken content. It’s under the Develop menu and will show you what is wrong and provide you with the option to remove or replace the broken content, whether a field, view, explore, or model. 

I just edited this as I realize this won’t capture source changes. Pardon my newbee-ness.