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.
this post was submitted on 23 Jul 2024
4 points (100.0% liked)
Learn Programming
1631 readers
1 users here now
Posting Etiquette
-
Ask the main part of your question in the title. This should be concise but informative.
-
Provide everything up front. Don't make people fish for more details in the comments. Provide background information and examples.
-
Be present for follow up questions. Don't ask for help and run away. Stick around to answer questions and provide more details.
-
Ask about the problem you're trying to solve. Don't focus too much on debugging your exact solution, as you may be going down the wrong path. Include as much information as you can about what you ultimately are trying to achieve. See more on this here: https://xyproblem.info/
Icon base by Delapouite under CC BY 3.0 with modifications to add a gradient
founded 1 year ago
MODERATORS
Where did you learn TDD. I mean I know the concept, but are there good courses for how to implement it into modern web stacks like React, Svelte etc
Saying I learned it is a stretch, we still dont use it at my workplace and I just read some random guides and tried it on my personal projects. I also wouldn't know about using it in frontend, I mostly just use it to make it easier to test my backend (c#) methods during development without having to struggle with setting up reproduction steps and go through the entire frontend every time.
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!
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.