I am really struggling to include proper testing practices into my code and would appreciate any advice on how to get going. I work in web dev so my I am interested in how to properly implement a suite of tests for websites and incorporate into it a CI/CD pipeline.

I find a lot of tutorials teach the most basic types of unit tests, 90% of the time most instructors teach how to write a test to sum two numbers, but when it comes to writing real unit test I find it hard to know what I should be testing. I learnt some cypress and have gotten better at including end-to-end testing because that makes more sense to me, but I still feel I am way short of where I should be.

How can I move forward? Did anyone else find themselves in my situation and find good resources to help them learn? Thx

  • It’s odd that functional testing feels easier to you than unit testing; I find the opposite, and that unit tests force better structure into my code. I write fewer monolithic mega functions and more, smaller, simpler functions that can be unit tested.

    Maybe it would help to approach some code in reverse to how you’d normally write it. Test-first development. You write your functional function, but make it full of stubs you think you’ll need to call - top-down design. Then, write unit tests for those stubs - they can be simple at first, basically pass if they get some expected result, and fail otherwise. Then run your tests and confirm they all fail. Then, one by one, fill in the stubs, every time running your tests and watching as more and more tests pass.

    This approach has a number of benefits:

    • test-first development encourages writing smaller, more easily understood functions
    • test-first development gives you high code coverage, which helps prevent bugs from creeping in during development
    • there’s a definite positive feedback endorphin reward from writing watching more tests pass as you develop, which encourages you to keep tests up to date and running clean

    Test-first is easier in some languages than others, as unit tests are easier in this languages.

    I hope this helps!

    • lmaydev@lemmy.world
      link
      fedilink
      arrow-up
      2
      ·
      edit-2
      4 months ago

      100% this.

      The majority of the times if you are struggling with unit tests it’s because your code isn’t testable.

      It felt weird at first writing code with tests in mind but, as you say, it makes your code much nicer to consume in the long run.

  • Perma@programming.dev
    link
    fedilink
    arrow-up
    3
    ·
    4 months ago

    So, I had the same sort of struggle a while back. And I have managed to fix it, recognizing what I had been doing wrong.

    1. I did not know how to test different parts of my system. Going through other people’ s testing example actually helped me a lot in this respect.
    2. I did not separate the complex internal logic of my program, from its side-effects. For example put the mapping of the data in the same function as I was doing external requests. You learn how to manage problems like this by practice. But of course, be mindful of the side-effects of your functions. Avoid it when you can.
    3. One other problem I had was that I wrote every test in the same manner. Tests that are not idempotent, and depend on external services, are useful, but you should use the facilities of your language to run them separately from your unit tests. In rust for example we use feature flags.

    Testing and writing functions that can be tested are skills that need practice. For me, many of the patterns of the functional programming helped a lot. Since they insist on pure functions and pure functions are massively easier to test. Learning how people manage to write programs with pure functions may help you a lot, too.

  • Cyno@programming.dev
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    4 months ago

    A bit late to this thread but what helped me a lot was when I started doing TDD. By testing my code against tests before its fully done or even implemented in the main app codebase (so to speak), I could break down individual tasks in it more easily and see how its interior parts work. It seemed easier to separate it into SRP areas since they’d have to stick to the unit test for that responsibility. Do keep in mind you can take it too far and overengineer it in this way but it was a good kick in the butt to get me to think in a different way.