Testing at Gizra
We have covered the subject of automatic tests quite a lot here at Gizra and I’m sure that there are a lot of posts and articles covering the subject. However, I’m having a bizarre experience lately while writing new features that I had to share it with you folks. Keep in mind that I don’t write a lot of blog posts and I always feared following up on my previous smashing hit Bootstrap custom breakpoint :)
Articles from Gizra
Testing at Gizra
Chances are that you already use Travis or another cool CI to execute your tests, and everyone politely waits for the CI checks before even thinking about merging, right? More likely, waiting your turn becomes a pain and you click on the merge: it’s a trivial change and you need it now. If this happens often, then it’s the responsibility of those who worked on those scripts that Travis crunches to make some changes. There are some trivial and not so trivial options to make the team always be willing to wait for the completion.
Once you start writing apps (and packages) in Elm, it’s
Yet when implementing features for paying clients, it doesn’t always make sense
them in pure Elm. In fact, sometimes it isn’t even possible!
I tell my kids all the time that they can’t have both - whether it’s ice cream and cake or pizza and donuts - and they don’t like it. It’s because kids are uncorrupted, and their view of the world is pretty straightforward - usually characterized by a simple question: why not?
And so it goes with web projects:
Stakeholder: I want it to be like [insert billion dollar company]’s site where the options refresh as the user makes choices.
If you happen to know Brice - my colleague and Gizra’s CEO - you probably have picked up that he doesn’t get rattled too easily. While I find myself developing extremely annoying ticks during stressful situations, Brice is a role model for stoicism.
Combine that with the fact that he knows I dislike speaking on the phone, let alone at 6:53pm, almost two hours after my work day is over, you’d probably understand why I was surprised to get a call from him. “Surprised” as in, immediately getting a stomach ache.
Chances are that you already using Travis or another Cool CI to execute your tests. Very often getting boolean or textual output from the execution is enough, because knowing which tests are failing is a good starting point to start to debug the problematic code. In our case, with WebdriverI/O (WDIO) and with an architecture where the frontend and backend are decoupled, it’s much more complicated.
Elm, like any rising open source project, is getting both positive endorsements and negative critiques. Reading the good ones, is always fun; but the negative ones are just as important.
Today, I came across this: Elm Is Wrong, and realized that I’ve always read the good and bad critiques from a technical point of view, but I have yet to read about what it means from a business perspective.
Baseball, Apple Pie, and Web Frameworks
I like baseball better than football (the American version). Football is a game of inches – but it’s measured in yards. Imprecise scope is built into the system. Baseball, on the other hand, is a game of wildly random occurrences that are often measured to the third decimal place. An entire framework exists to understand the smallest, yet important, details of the game.
I work at Gizra, so it was only a matter of time before Elm infected me as well, and I think it’s growing on me.
I wanted to build something a little different, not just the plain old TodoMVC. So, I harnessed every bit of creativity I had and came up with the most radical idea ever - I took the TodoMVC in Elm and got it to work in Electron, and called it
Elmctron (I know, so creative of me).