Learning a new language while on a project at work has meant a somewhat rushed learning curve. I’ve had to learn functional programming, Elixir, GraphQL, graph databases namely Dgraph and dabble in ReactJS. This has lead me to cut corners, mainly testing. I haven’t put any effort into learning how to test, I’ve more or less been pushing features out and moving onto the next thing, learning each step as I go. This works somewhat with compiled languages and even better with functional ones as the lack of mutability leaves less places to screw up. Still you need to test and I am a big believer in testing, I’ve just never worked on project for more than 10 minutes. My boss made a bigger push to get testing done now that we are starting to understand Elixir more and I was tasked with adding tests to my Dgraph queries and mutations as well as my CSV importing. It was so easy, well once I refactored my complete and utter mess that was my code it was easy. I spent a few hours breaking everything up, making it nice and clean and reusable. I then set out to unit test the basic functions I had created, not only was it quite easy with the built in ExUnit, but it wa extremely satisfying, seeing green everywhere. There's something strangely satisfying about seeing all your tests pass and even more so when you go and change around your code to make it a bit cleaner or more efficient and the changes you think will work, actually do work and are proved by your tests. It really gives you the confidence to change your code around and try different things to see what will and won't work. The only problem that I had with testing was when I ran them locally they would all run, but when I ran it in the build pipeline on Bitbucket some would run and others wouldn’t. I even ran the same seed which is generated after each test to see if that particular seed was the issue but no matter what I tried they would run locally yet wouldn’t run in the pipeline. I would say this has something to do with how we set up the pipeline, we don’t have a devops person yet but we are contracting one for a few days to fix it all up. Most languages have these built in test modules which gives you one less obstacle, tempting you, guiding you into testing your code and you should test. Everyone and your mother tells you to test, but I’ve found that the best reason to test is to give you the confidence to say yes its not broken and any changes you make can easily and quickly be verified. For if it wasn’t for the couple of tests I wrote it would have taken me 10 times longer to establish if each change I made broke the functionality.