The Case for Writing Protractor Tests in TypeScript

If you're reading this not too long after I decided to start this project (January 2016), you may have realized this is a lonely road. A quick Google search of "protractor typescript" pulls up very few relevant results. You'll see this blog, TypeScript-Protractor, one or two other blogs (like this and this one in German), and some Stack Overflow posts. You'll find type definitions on the DefinitelyTyped repo linked on NuGet and others. That's pretty much it. If you look up TypeScript in the Protractor issue search on Github, you'll see Julie Ralph (Protractor team lead dev) has TypeScript (TS) on her radar. She's not looking to rewrite Protractor in TS but she thinks including definition files in the package is a high priority. It still makes me wonder if there's a good reason not many are doing it and talking about it. It seems like the TypeScript-Angular is a thing, so I ask myself what makes e2e Angular testing any different. 

Then why the heck am I doing this? 

1. TypeScript is the language of choice on the development team I'm on so e2e test development in TS would be consistent with their production code.

2. TypeScript prevents trivial errors, makes code more readable, and at compile time will help find simple bugs that might otherwise slip through or be hard to find with a stacktrace alone. 

3. I already know what types variables are supposed to be and I know what types functions should return so I might as well put it in the code, right? How hard could this really be?

4. It's new, uncharted territory - at least from my e2e testing perspective. Writing in TS would be a challenge for me because it's new. I'm forced to figure it out the protractor-typescript link on my own. I used to hate strong types because I felt like it was slowing me down, but I think maybe I just need to grow up. 

5. No one that I know of suggests otherwise. I have the definition files and I've been tasked to create a reliable automated e2e testing framework in a reasonable amount of time - from scratch. If that were not the case - like if I had a framework already established - I might not pursue this. 

This might end up being an utter failure. I might never write in this blog again. It could be a hassle, take too much time. I might lose motivation. I might need the speed and community support of javascript. Who knows. 

However long or short the journey, thanks for reading and riding along.

And please comment!