What are you biggest pain points when testing your code?
Hey guys! I'd like to know other devs' thoughts about testing. I'm particularly curious about its pain points since I've suffered quiet a few during my career as software developer.
I know indiehackers tend to leave tests for another day ;), so even if you don't usually write tests, I would love to know why!
When it’s one or two people I don’t see much value in tests. More important to put time towards building things I think
I thought the same coming from a Java background, but after starting work on my own app with Python (Django), I realized how the developer experience of unit tests is like night and day for these two technologies. I barely ever use postman to test my endpoints for example, because I can spin up a few unittests almost just as quickly and have the lasting benefit of knowing when my code breaks.
Huh...I'm using Django as well. Maybe I'll have to take a look
For sure at least give it a shot. So nice it spins up a dummy database and everything - you don't even need to "mock" most things you would need to otherwise.
Yup, I totally agree. Have you ever regretted that decision? Or have you ever said something like "oh jeez, this wouldn't have happened with a few tests"?
I've never had something go big enough for it to matter so I guess I haven't haha
haha fair enough :)
I probably have an opposite opinion to most people on IH. When the product becomes just a little bit more complex then the "end to end" tests become super valuable for testing a happy path. So you don't look stupid that something very basic is broken and you didn't notice for 3 days. The time is valuable and we don't have time to test the whole app every time we change something.
And it's really great if your tests are from the beginning integrated into your deployment pipeline, and that pipeline you can reuse to other projects in future. Also, It's much easier to add another developer to the team if automatic testing is part of your process.
Don't need to test everything, but you need to have some common sense of what is crucial ( I think that will be probably about 30% coverage )
Also, writing tests will pay off if you one day you start working on a big startup with 100+ people.
This comment is great! I also think that devs need to have some common sense about what to test and that testing a few happy paths can prevent you from some headaches in the future!
I find particularly interesting what you've mentioned about the integration with the deployment pipeline. Is it hard at the moment? Do you know what's the best solution at the moment to achieve something like this? I have little to no idea about this...
I was thinking about Jenkins but there are many alternatives https://www.guru99.com/jenkins-alternative.html
It could be even the bash script which on every merge to master run all the tests and publish site if they all passing correctly.
My biggest pain point is usually figuring out what to test and what not to test.
Interesting! Could you elaborate this? Is it because you have so many un-tested features that you don't know where to start?
I'm mostly talking about automated tests. The list of things you can test is almost endless, but there's never enough time. Some things are obvious candidates for testing: input validation, any algorithm that does some kind of calculation or data transformation/formatting, anything related to compliance or legal obligations, etc. But what about testing the UI layout, making sure components are rendered on the page (e.g. login form), colors to ensure you're following the brand guidelines and not violating 508 color contrasts? Do you test that your APIs update the database how you would expect them to? How much performance testing should you do, what should you measure, and how much of it should be automated? Everything is a candidate for testing, but some things cost a lot more developer time than others to test, and some things aren't as valuable to test as others.
Exactly, I think most of us here agree that they simply take too much time. Have you ever tried to find a solution for this? Maybe with some kind of "testing as a service" platform? I've seen a few like this, but I'm not sure how good they are.
In indie contexts it's just sometimes not worth it.
It's a fwd looking investment that would probably not pay off
As most projects would die not
It pays off only if it grows big enough that you don't remember it all and/or add team members..
I think @nickchuckwalter and you have a similar vision. As I said to him, I also agree with this. Have you ever regretted that decision though? I've seen some startups that regretted not having a few tests in some critical parts of the product.
It's that silly story of things after a step looks totally different.
If you're on top of the businesses had success hill when growing the company now and adding engineers, you would "regret" not doing testing earlier.
But you would probably never have ended there in the first place had you done testing earlier.
Interesting point. I guess it doesn't always apply, but in some cases it definitely does.
Oh, I feel you! I also think that the amount of time setting things up is ridiculously high... Have you ever tried to find a solution for this somehow?
When possible I copy paste a lot from something similar I can find.
I did have business ideas around it, but they are pretty big, and would be a huge uphill battle with multiple parties to convince... Due I'm recently more into chunking down so I can probably can come up with something...
I would note that there are plenty of companies around that would copy a solution that works in a heartbeat IMHO, so I think solutions can be had, but not sure about profitability
Yeah, I think the optimal solution for a problem like this should probably be FOSS. But I also believe that there are plenty of opportunities in this field to build something profitable.