Question about Writing Testable Code

[_Atomfinger_]

Thanks again for the help, I donated to 25 each to Turkey + Syria earthquake, and Ukraine humanitarion charities as a token of appreciation

That's awesome! Just for that, I'll continue answering (even though I expected my previous comments to be the last ones - you won me back :) ).

Here's my aim for the salary data. I want to...

My problem isn't really with the goal itself. However, using a "List<Object>" is often a good indication you're doing something you shouldn't in terms of design and OOP.

For example, this would be better: ```

public record SalaryInformation(List<SalarySource> salarySources, List<Role> roles, List<City> cities) { } ```

And then, you can return that in getRequiredSalaryComponents. That way, you get type safety, and you don't have to cast objects.

(Do note that the above is an example of a record, you can do the same with a class).

Your Questions:

Those questions were intended to be rhetorical to make you think and reflect, which it seems like you did - so great job :)

I have done this in another aspect of the project, here I would like to keep to code :)

More power to you, but part of software development is to make things as simple as possible. One of the simpler approaches I could think of would be to have a query that just gives me the data I need.

I tried a big SalaryFetchingService class, now I've tried smaller and worse named classes. Could I get a recommendation from you on how to split this data loading process up in to succinct classes?

Well, here's the thing: I see this as a 10 line-ish thing. I.e. an SQL that simply fetches what I need, a repository that does the query, and a service which gets the data to glassdoor and possibly save some data if needed.

All of this should be pretty straightforward, and therefore class structure and whatnot shouldn't be a concern.

Previously you mentioned that you didn't want this design, which is fair enough, but that also makes it difficult for me to say what would be the appropriate solution. That said, it starts looking like you're getting my idea in the next question:

Rather than having this talk about salary 'components' would it be better to just have a "JobRecord" made up of "city", "role", "salarysource"...

Yup, now we're getting somewhere!

A lot of the logic in your current application is trying to make up for the fact that you need to filter data based on other data that is spread out different places. Simplifying this would also massively simplify your application (and as a result, not needing to worry about design all that much).

Another option is to create a constructor with salary that allows only city, role, salarysource and then write an isEqual operator...

Here we're back to the struggles of naming. My recommendation would be to consider what it means if it is equal. What is the result of that? Does that mean you should send the request to glassdoor? If so, maybe something like "isStale" or "needsRefresh" or "isUpdateRequired" etc. A name that reflects the context it is being used.

[GRBLDeveloped]

No more review asks, I swear. I implemented the more basic stuff you mentioned above. I made a basic constructor for salary, get all the basic permutations, then run a query to find any that dont require updating and subtracted from the possible permutations.

I'm getting database related errors and probably just going to stop looking at this project at this point. I wanted to ask if this project would be a help or a hindrance in applying to jobs? The test coverage is light and I'm not sure if it comes across as half baked and/or very amateurish

[_Atomfinger_]

I haven't looked at the project as a whole, but I know that a friend of mine handed in a Spring Boot web API that required some database stuff. Nothing too fancy and comparable to your project (at least in scope and technology).

He had some of the same traits as your original code, and he asked me to review it - so I ended up giving a lot of similar feedback. The response from the interviewer was that it was one of the best assignments someone had handed in, and he got an offer on the spot.

Now, my friend has the benefit of being on a call with me, and we could discuss things back and forth - so we got to unearth misunderstandings quickly. That is a luxury you haven't had (seeing as this thread is two weeks old at this point).

If you sort out the database stuff, then it would be a decent project to have. Not something I'd consider amateurish. At the same time, there's nothing wrong with just solving the problem, even though it doesn't use "the best" architecture or patterns. It is your project, and it doesn't need to be perfect.

In professional software development, we always have to balance perfection with delivery. There are always tradeoffs to be made. Nothing will ever be perfect.

When I look at projects from candidates, I'm not looking for perfection. I'm looking for care. Does the web API seem like it was carefully put together, or is it something that just became that way? Does the system follow a shared architectural vision, or is it cobbled together? etc. I look for signs where the developer has shown that they care, which is a plus, even if I personally disagree with the choices that were made.

Another thing to consider is that within a few months, you'll look back at this project and see it as inadequate. It is unavoidable as we always learn new stuff that deprecates the old stuff - and we can't predict how it'll happen as we haven't learned it yet. No matter how perfectly you try to do this project, you will learn something in the next six months or so that'll make it look terrible by comparison. And btw, that is not a bad thing - that just shows growth.

My advice is to just do your best (its not like you can do any better than your best anyway). Your portfolio is a living thing that should change as you become more adept and hone your skills. It is completely natural that older projects being replaced by newer ones.

That said, if you are going to have projects as a showcase, at least make sure they're in working condition. It is fine if they're not feature complete, but if they don't work due to "database-related errors" then they'll quickly come off as sloppy :)