3 ms·

Is the current API under test? Your number #1 priority with any port or major refactor is getting the current implementation defined and under test, so any rep

Is the current API under test? Your number #1 priority with any port or major refactor is getting the current implementation defined and under test, so any replacement can be tested against the same tests. Once you've done that you should have a solid foundation and understanding of what the API actually does. In getting it under test, you'll also build up better mental models of which parts are actually separate and easily testable and which parts aren't. Then you can get to work replacing and testing each unit, then build them back up on the other side.

Buttons840 4y ago
You're right, that would make me feel a lot better about this task. Adding tests around the existing API is something I believe I could make progress on, this is a chunk I can break off.
jsomau 4y ago
Adding to this: > By the time I'm down in the weeds I've forgotten what I'm doing, what the purpose of the actual API call is. If I can craft tests up front in terms of the higher level goals then when I finish a subcomponent or get distracted by something else the higher level test is there for me to fall back on to figure out what to do next.
linuxftw 4y ago
Great advice, I was going to suggest the same. You shouldn't have to memorize what each layer of a project does, that's what the unit tests and integration tests are supposed to prove.
aeschinder 4y ago
Is the current API testable? So many times I've taken ownership of code that requires an active connection to a database to even be up and running. Changing the code so it's testable usually changes the code so much it is very hard to have confidence it works the same way as the original implementation. My old company lived and died by its instrumentation of DAU (daily active users). We would try to refactor the code to an IoC pattern with DI but invariably we'd get blamed for a downturn in the numbers - but never lauded if the reverse was true. It was a losing game - we finally had to get management to commit to the modernization (never, ever say "rewrite") and power through the days of low DAU.
- therealdrag0 4y ago
  How would DI impact DAU?

Buttons840 4y ago

You're right, that would make me feel a lot better about this task. Adding tests around the existing API is something I believe I could make progress on, this is a chunk I can break off.

jsomau 4y ago

Adding to this: > By the time I'm down in the weeds I've forgotten what I'm doing, what the purpose of the actual API call is. If I can craft tests up front in terms of the higher level goals then when I finish a subcomponent or get distracted by something else the higher level test is there for me to fall back on to figure out what to do next.

linuxftw 4y ago

Great advice, I was going to suggest the same. You shouldn't have to memorize what each layer of a project does, that's what the unit tests and integration tests are supposed to prove.

aeschinder 4y ago

Is the current API testable? So many times I've taken ownership of code that requires an active connection to a database to even be up and running. Changing the code so it's testable usually changes the code so much it is very hard to have confidence it works the same way as the original implementation. My old company lived and died by its instrumentation of DAU (daily active users). We would try to refactor the code to an IoC pattern with DI but invariably we'd get blamed for a downturn in the numbers - but never lauded if the reverse was true. It was a losing game - we finally had to get management to commit to the modernization (never, ever say "rewrite") and power through the days of low DAU.

therealdrag0 4y ago
How would DI impact DAU?