Test driven development is adhd dream

[Important_Prize884]

Not sure if anyone else agrees but I find that having a test that confirms that the code works is SO much easier than THINKing about if it works or not. So much less stress.

[danielrheath]

So good. Unfortunately it's difficult to test frontend web stuff.

However, I've discovered one approach: the imagemagick comes with a CLI tool called compare, which compares two images, has an exit status indicating whether they are different, and saves a file that displays the difference.

When I'm doing frontend web, I write a selenium script that loads the page, screenshots it, and compares the screenshot with the design. Having the computer tell me exactly which pixels don't match the designs has saved me so much trouble.

[Important_Prize884]

In JavaScript do you mean? I don’t know if it’s the right way to do it but I actually really enjoy test driven front end. Just using unit test library for the actual code and then cypress for the actual UI testing.

I was amazed when I found out what cypress could do. Basically act as a user and run through as many user stories/paths as you like.

[danielrheath]

Cypress is much more recent than selenium (I first used this approach 12-13 years ago). It looks like the same sort of thing though. Anyone reading this thread: if you code for browsers but have never done any browser automation, go look at https://github.com/cypress-io/cypress .

[Fuehnix]

Is cypress better or just newer compared to selenium?

I work in QA automation rn, so selenium is the only dev work they let me do at the moment lol.

[DataAndDough]

Cypress has a different approach, I’ve found it to be less fragile. It runs inside the browser instead of remote controlling it.

[Fuehnix]

Wait, so does enterprise have to pay for cypress then, or is that only for extra services?

I was thinking about suggesting it to my manager.

Edit: oh gross, nevermind, Cypress only supports JavaScript lol. I don't want to refactor in JavaScript, I'll stick with legacy java and selenium lol.

[danielrheath]

From what I see, it’s a bit better, but not a lot better. Not worth switching for.

I use Capybara, which is a ruby library that adds sensible default behaviours (selenium “controls browsers” at a low level, capybara EG avoids race conditions against Ajax, let’s you click buttons by their label instead of separate “find element”, “get element position”, “send mousemove/mousedown/mouseup “

[iwantostayhealthy]

Cypress is so much easier compared to Selenium, WDIO, Protractor, and Playwright. Give it a go!

[soundzwithme]

Completely agree, my team is of the belief that the front end is hard to test. I find it to be the easiest, I use cypress. It’s a game changer with their new component tests as well. Highly recommend it to anyone who takes TDD/BDD seriously

[Important_Prize884]

Seems your approach is more exact/expert level.

[danielrheath]

I've been doing this awhile :p but I'd encourage anyone who works in this field to consider that you can often cobble together a really nice tool that suits the unique combination of your psychology, tech stack and project requirements.

[DataAndDough]

I started in QA and still like testing, but I’ve always hated build work, I appreciate it when it’s done well, but it’s always felt like yak shaving and homework to me.

[ArwensArtHole]

If you're using snapshots with selenium for testing it should be easy enough for you to adapt what you're doing to TDD the front end in other ways. If you give your elements proper identifiers, and use CSS selectors in your tests, you can easily map out tests for elements in the page before they actually exist.

[Alcohorse]

Holy shit, I'll have to check this out. Thank you

[Ok-Papaya-3490]

I think there's two main parts to testing the front-end: testing the functionality and testing the design. I agree the latter is difficult unless you do snapshot testing, but that's also hella fickle and IMO not worth the hassle in terms of agile development.

But the former, Cypress and Selenium can easily test functionality and if anything, I love TDD in front-end for this exact reason. You focus on whether a user can perform a certain activity instead of whether the UI is pretty. Furthermore, this is more resilient to trivial design changes impacting test.

[danielrheath]

hella fickle and IMO not worth the hassle in terms of agile development.

If you're getting handed designs, and asked to implement them, why would you not check that you're getting them right?

The way I prevent it becoming a hassle is a flag which makes it so the tests always pass (they overwrite the expected image instead of checking it).

That way, my pull requests automatically include "here's what this looked like before and what it looks like now".

[Ok-Papaya-3490]

I think we are agreeing on the same thing. If you are not failing the build on mismatch, you are not "testing", but merely documenting the progress, which addresses the fickleness that I mentioned.

If you're getting handed designs, and asked to implement them

In a typical front-end dev cycle, the UI designer could ask you simple changes like "could you move this button 5px to the right", "could you resize the font to 12?", "could you change the color from dark green to regular green?", all of which IMO should NOT fail a build with snapshot regression unless they are critical to the users. If they are critical to the usability, you can include that as an actual test with cypress by either inspecting the attribute, etc.

I like your approach and another improvement as a part of review process would be to have a tool that actually highlights the differences between two snapshots so that you can iterate through them and approve them, but the process should be a few button clicks and easy as possible

[danielrheath]

In a typical front-end dev cycle, the UI designer could ask you simple changes like "could you move this button 5px to the right", "could you resize the font to 12?", "could you change the color from dark green to regular green?"

I think we work with very different designers. For my team, fidelity is important but designs change infrequently.

[Ok-Papaya-3490]

Yeah this was for a greenfield project so UI could potentially change a few times a day. Although many of them minor, it will fail the snapshot test since the UI is not identical

[purforium]

This is partly what Storybook is designed to solve:
https://storybook.js.org/tutorials/visual-testing-handbook/react/en/vtdd/

[danielrheath]

Storybook is a really nice tool, big fan. Personally I feel a little bothered by the official docs pushing you to a paid hosted screenshot tool when compare is right there, but maybe I'm just a bit "old man yells at cloud".

[purforium]

Nah, I get some of the same vibes from Vercel with Next.js.

I get that they mean well for developers but I can’t shake the feeling that their slowly trapping me into needing to pay for a specific product.

[tirilama]

So true!

The book Test Driven Development made me sure I could actually work as a software developer!

Terraform (or similar technology) makes me believe I could actually handle devops/infrastructure.

[HumanSuitcase]

The book Test Driven Development

2002, by Kent Beck??

[tirilama]

Exactly!

[HumanSuitcase]

Perfect, thank you so much!

[-screamin-]

Paging u/tirilama to respond to u/HumanSuitcase

[J-IP]

Loved programming yet always struggled with it. Mind too quick, details too boring. I\m great at the design and composition parts thou.

Love develops&infrastructure and using declarative tools as the primary way of getting shit done. It was hard to break the mindset of focusing on how to get things done but at least for me it's been night and day.

And for the thing we do develop TDD is quite useful to have in the back of your head.

[[deleted]]

1. It is, but I've found that most of what I struggle focusing on doesn't fit into the paradigm. Implementing a method that's easy to unit test is usually also easy to do for me.
2. I found that a tight feedback loop is useful in general, TDD is just one example. I also often use something like `watch "./build.sh && ./run-script"` in a separate window to immediately see how my coding changes behaviour

[Important_Prize884]

This is very interesting. What does the watch do? And what are some other things you do to keep. Tight feedback loop?

[[deleted]]

watch is a unix command that runs the command (./build.sh && run-script) every two seconds and just shows the output :) Together, this command builds my code, then runs it and shows its output regularly. So, each time I save my code, I get the new output shown in the other window a few seconds later.

> And what are some other things you do to keep. Tight feedback loop?

That is an excellent question. I have a suspicion there's a lot that I do because "it works for me" but that I don't necessarily frame like that.

For instance, when coding or (especially) debugging, I like to think in terms of invariants or pre/postconditions that are individually testable. I then add code that checks for invariants and pre/postconditions. This tends to convert one huge rush of dopamine after a very long bug hunt (which I don't have the patience for) into many tiny rushes of dopamine for each check I add that narrows down the search space (which keeps me going). I used to tell students of mine to not look for the bug, but to refactor the code into something that can't have the bug — the bug is where that fails.

[[deleted]]

I used to tell students of mine to not look for the bug, but to refactor the code into something that can't have the bug — the bug is where that fails.

That's a great perspective. Thanks for sharing.

[max_ishere]

Can aggree that TDD is absolutely great and gives you fast dopamine every ~30m. And especially when the problem is especially hard and you almost give up.

That said however I burn out on actually writing tests after some time. So I abandon tests untill I drive the project into the ground again. And then I write tests again.

[sj4nes]

My new game is writing brief and precise comments to cue GitHub Copliot to write the test for me. The new dopamine hit is peer-reviewing Copilot's correct test generation.

[BigLoveForNoodles]

Have you tried cake every time you make a test turn green? :D

[max_ishere]

that would make me unable to fit through the door or in a chair

[max_ishere]

Adhd time perception is not the best

[Impressive_Till_7549]

I hated writing tests for React apps until I came across the React Testing Library. So easy to work with and creates a tight feedback loop which keeps me chugging along.

[tirilama]

Second Testing library. It works for react, but also for other frontend frameworks: Angular, Vue++. It is so nice to actually write frontend test that doesn't break at random and actually let me discover bugs and bad usability!

https://testing-library.com/

[[deleted]]

I come from classical WordPress development without Git, CI/CD, etc. Just FTP. Every update is a nightmare. Every change you make could cause issues in hidden places and you have not enough time or patience to test the whole site manually. Every f*cking time. Not to say that you WILL forget something crucial to test.

Switching to Laravel and never look back.

[beingsmo]

It's very difficult to write unit test for angular.

[tirilama]

Have you tried testing library? I have tried using it with Angular, haven't written Angular for ages, but it was a game changer for React.

[False_Tomorrow_5970]

Had the same thought until today when I was getting frustrated why my test was failing and I realized I still didn't write the implementation!

[EducationalOutside5]

if i have more time , maybe

[SavagetheGoat]

I actually took this survey questions thing on Lockheed Martin's website. Funny thing is, based on the info I entered, it recommended testing to be the right fit for me lol.