Arrgh...

I need to do a lot of refactoring and testing (%80 percent of which is integration) and ITS SO TEDIOUS!!!

Now, for anyone who says "oh, you write spaghetti code, your code shouldn't be so tedious to refactor". No. It's only tedious because it's a few thousand lines that I've been too lazy to refactor till now, and I need to go through it all.

Anybody have any advice for refactoring or testing in Go?

Goland can help. It'll tell you things like code duplication, mechanical coverage, and has a stubbing mechanism. The last bit isn't helpful to me as I do e2e style unit testing and only exercise the public interface.

I'd have a general advice.

Try divide and conquer.

Nearly everything can be broken in small units.

Eg you've a HTTP library. Which you need to abstract.

What's the smallest unit?

Usually a request.

Try to do it per request then.

GIT is your friend. let it be a 1000 commits. You can still squash them.

It's an tedious progress, but it lets you focus on one single thing - and when you have finished it, you're done.

In my opinion, this is the easiest way. As you operate solely on one thing, and you can easily prototype stuff for one thing, testing becomes easy.

At the end, you'll know enough about each of your libraries ""again"", that you'll have a good perspective what needs polishing and what not.

@SortOfTested hmm, didn't know it had a thing for duplication! Also, what's "a stunning mechanism"?

@IntrusionCM yes, but the issue is that 99% of my requests deal with a DB, which introduces a whole new level of complexity...

@chabad360 it was an example ;)

I really really really hope that you've seperated the database logic from the rest...

@chabad360
Android autocorrecting the term "stubbing"

@IntrusionCM oh yes, although there are a few places that need fixing. I recently moved to an ORM, had to rewrite the whole DB layer, but on the plus side, I eliminated about 300 lines of wrapper code.

It was fun.

@SortOfTested ah... But for testing that's a bit useless...

@chabad360
I mean, it stubs tests. If you're going for mechanical achievement hunter it's a thing. I said it had limited value.

@SortOfTested well, I kinda find that useless...

My main fear with tests right now, is that I don't have any stable API yet, so I keep changing things and the tests start failing again, which means they need to be fixed, and that takes some time...

@chabad360 hmmmmm.

Do you currently have milestones or a clear perspective what you want to achieve?

Sounds a bit like you've lost yourself and try to eat more than you can chew

@IntrusionCM I have milestones, but I also have ADHD which messes with my motivation, and this is the kinda stuff that makes it easy to lose motivation...

@chabad360
Sounds like you need to document your domain, as well as the resulting entities and DTOs and your test cases. Your domain should be mostly static. You should be able to test your public interface with no more than 5 or 6 tests per endpoint at a stage with a formative domain.

@SortOfTested the API documented (openapi) it's just a pain to integration test 13 endpoints.

@chabad360 how do you manage to trot along on the dev path with adhd? I know adhd is a spectrum, but observing the adhd peeps close to me I have come to the conclusion going dev would never suit them (apart from the few I know that are autistic as well)

Edit: definitely not bashing you as a dev because you have adhd! Quite the opposite! Just really interested in how you make it work

@100110111 I do two things, meds and good motivation. My meds make much more possible for me to do tedious things, and motivation comes from the sense of accomplishment from solving a problem.

Which is the main reason I dread refactoring and testing, not because my code is bad, but because there's no real problem solving.

@chabad360 I have a solution for you: start seeing the problems that refactoring and testing solve as real problems. Refactoring solves messy code and messy code IS a real problem

@100110111 yes... But there's no real sense of accomplishment that comes with that.

It's not the problem I'm after, it's the good feeling after finding the solution.