This article was originally published in Typeform's Engineering Blog
Part one: OMG I'm totally buggin!
I’ve been hearing about the impo...
For further actions, you may consider blocking this person and/or reporting abuse
All excellent points.
I've worked in a few environments, some with tests some without. Some of them were even huge systems that had no unit tests.
The people working there were so smart, so very clever. They had to be to keep it all working. I couldn't really take it, it was just too taxing for me.
For me it's a matter of scale. Tests let me work on big complicated systems because they document how a system works and gives me freedom to play with specific areas of the system without fear of breaking them. Plus I don't have to understand the whole system in order to make changes.
Working in a TDD manner I almost describe it as "dreamy". You just break down the problem into small tasks (imo, this is the #1 skill a software developer needs to learn) and then gradually iterate, writing tests for more requirements and refactoring slowly and surely with minimal stress.
It's why I work hard on this quii.gitbook.io/learn-go-with-tests/ because i 100% believe that TDD is an enabler of high quality, less stressful software development
It's why I advocate for releasing on fridays too dev.to/quii/why-you-should-deploy-...
I've been meaning to learn go so I can join the backenders mob programmings (and actually follow along).
This might be a sign from destiny.
Yes!
Go is a lovely language to start with it too because it's all built in.
Do let me know if you give it a go (pun intended) and I live for feedback.
Better still, contributions very welcome
Will do!
Agree with you!
Few months ago I've make a presentation about TDD and described it as some practice that delivers us up from loosing concentraction ind fear of unknown bugs. So I felt that many people have wrong impression about testing, like "tests consume a lot of time", "tests aren't code: they're not bring functionality", etc. After my explanations & examples they changed their minds on tests. That's why I'm concern: there's a need to bring this knowledge to the people.
Thank you!
"and bugs, and anti patterns, and bad code, and monoliths", which all can be fixed anytime if you have tests!
Also they are good for documentation, you can understand what the code suppose to do, even if it has the worst naming conventions and you do not know the language!
For me the biggest advantage is the ability to refactor without having to prey before the release! This transforms a code from a brick to a jelly bear, flexible, it can be bent to accept new features.
I like the idea of tests as documentation. I have experienced it first hand, going to the tests (unfortunately as a last resort) to try to figure out how something works, but I didn't think of it for this text.
Btw, you made me think of a brick of jelly bears... a catastrophe that can sort of work as a metaphor for some codebases out there 😅
I admit, it wasn't the best metaphor I've made up :D
Btw, my comment comes after an extensive experience on legacy code with 0 automatic tests. I've seen the ups and downs of monoliths, the pros and cons, and one thing is for sure, once you go tests you don't go back. They are not a silver bullet, they just make our life easier.
I've been a professional developer for 23 years and have never used automated testing in any projects. I've had a go at working in this way and just find that writing the tests slows me down and ruins my coding flow. For me, I feel it adds an unnecessary overhead to development
Hi Jon, I totally understand your comment. I've been a developer for more than 30 years; now It's just 10 years I'm into testing.
It was so difficult at first, I could see only a black mess without meaning and without form. But I was stubborn and went to a course to learn in practice.
Now I don't use tests on 100% of the project, but I know that some parts are easier to develop and maintain with tests than without.
To get there I needed a very big mental shift.
Hey Jon! I know in Software engineering we usually accept a lot of things as "revealed truth" and maybe never question them as long as they serve our purpose. I have found testing things thorough automation to be a revealed truth because it helped me work in what I feel is a better way.
And so, I'm curious about some aspects of your workflow, if you don't mind:
Just in case: I'm not trying to find a way to prove I'm right, I'm just curious about your context and workflow.
Technologies I work with:
Working in teams:
How to make sure everything works?
Using CI:
Testing taking a considerable amount of time:
Have a read of this
geepawhill.org/tdd-and-the-lump-of...
What do you think?
Reads pretty much the same as most articles promoting TDD. To me, it doesn't really reflect the reality of development (at least the way I do it). While I'm coding, ideas come to me thick and fast and I will often do a total u-turn on how a function is implemented or have a complete change of heart on how a large problem should be solved. The whole process is very fluid and organic - taking place in one place - without jumping 'out of the code'. Having to keep leaping out of that flow really does not work for me and I feel ends up with an inferior end result that took longer to produce.
I'm not sure if the way I learned to code has anything to do with my methods - quite possibly I guess as I am totally self taught - from the age of 7. I have no formal qualifications or training as a programmer - just 35 years of experience (about 23 professionally)
To add to this healthy discussion, this 3 part hangout series video is pretty good as well.
Lots of pros & cons perspective from 3 of the top many names in the software industry today.
youtube.com/watch?v=z9quxZsLcfo
My selling point for tests is refacting. If you cannot tests something easily (eg your setup/fixtures grow too big, you are inclined to use mocks and generally testing is problematic) - you have bad code, or worse some bad design/architecture decisions, the tests reveal that.Important and more rare skill is knowing what to test, and achiving meaningful coverage with fewer tests. The tests are never complete, cannot tests everything and under all coditions,it is becoming very exensive, so picking the risky parts of code for tests is super important.
Excellent post.
Where can I start? I know there are several testing tools, Mocha, Jasmine, Karma. What do you recommend?
Thanks!
If you're working with Node.js, I use Jest in my tests and it's pretty wonderful to use. I highly recommend giving it a shot 😊
P.S. Here's the Getting Started guide I followed when I first gave Jest a shot.
Jajaja I forgot to explain what language I use. Currently I'm working with C # for the backend and Angular for the front.
I've honestly never worked with either of those so I'm not too sure what your best option would be 😅
Hopefully, someone else can chime in shortly with some help though.
Thanks for the clarification, maybe you can edit your post to get this info straight at the first glance? :)
Hey! Thank you for your comment :)
I think there's 2 sides to this. First and most importantly I would devote some time into researching what and how to test your code. This is important and won't change much with tech stacks.
On the other hand, there's how to test with your current stack. I read it's C# and Angular. Maybe the best is to start by covering your backend logic, which should be more stable I guess. Look for a tutorial about unit testing in C# (of which I know very little) just follow it and then try to adapt it to your own needs. The tutorial should give you some idea of what and how you should test too. Start by the most critical areas of your app and move into more secondary features/code.
I hope that helps. Sorry I can't give more specific advice. Happy testing!!!
From all my years of developing in C and then in Java, they never taught me how to write tests in college (actually, once a teacher wanted to show JUnit and it was a Huge mess).
So now my question is more like, how do one learns to do TDD in JavaScript? with all the bunch of testing frameworks out there.
A very good introduction to doing TDD with JS is this book by Venkat.
It is an absolute piece of beauty, must read for all developers.
Test-Driving JavaScript Applications
pragprog.com/book/vsjavas/test-dri...
I know college courses rarely touch the subject, as they rarely touch many aspects of real-life / industry software development.
About js, I think it's the same as with other aspects of the ecosystem: it's not about the framework, it's about what you do with it. The fw should be only a medium, a helper to get there.
If you're really lost about where to start, there's always tutorials about the hottest and latest fw/library (even for testing). Pick one and try to apply it to your applications. If you see value in it, and it becomes a habit, you'll be able to translate it into any other fw that comes along.
Fwks should be approaches to the solutions: if you know the problem well enough then you can choose which one suits you best.
Awesome advice, thanks for sharing :)
A nice post explaining your journey which I imagine will be very useful for junior developers to read.
One minor edit to one of your quotes would be:
Even with tests you should be suspicious of your code :)
As one of my great co-workers would say "you are correct".
You can never "rest assured" of anything, really. It sounds like blind faith. There's always many implications in every feature or change, and even if you think you've covered everything, you can never be 100% sure.
Thanks for the feedback :D
Products change and maintainers change. These things exist for people and keeping a record of what people like or want in their software is challenging. Not only maintaining correctness but also joy. Applications rise and fall. I remember enjoying winamp and iTunes for a time. As a user I can tell when quality is being skimped or features are being packed in. I like tdd for quick feedback and hope we can find more ways to build in mechanisms into our software to make better products for people.
For me, I just find it fun to do so, specially with tdd, it's fun, and I actually find it quicker to develop, I have my tdd setup which makes me very quick, I never leave the ide
I'm already recommending this one 😄
On this general topic, I really like this post from the current DEV homepage:
Why do great developers love writing tests?
anabella
So honored to hear you liked it, @ben . Thank you and thanks for sharing :D
On a personal note I wanna take the chance to thank you for this platform and for your inspiring devotion to make it great every day <3
Thanks!!! You're 2 for 2 on absolutely delivering gold stuff for the community. So THANK YOU!
Looks like we have some bugs when it comes to multi-level liquid tag embeds. 🙃
cc: @maestromac
You can call them bugs or you can call them generative art. Up to you.
hardest working people in the business
Now I'm very curious about testing tests. It always sounded to me like the chain rule of calculus' derivatives.
I don't know much about calculus, but I do always "test" my tests (at least the first ones while I'm still setting things up) to make sure they're not just going green in any circumstance 😅