3 ms·

From experience, I find that I'm not really able to add meaningful tests until I have an idea of what's going on.

ljw1001 9y ago
I've had the same experience. I'm sure it's somewhat context dependent, but if the code amounts to business rules and they are not documented, which is very common, you can only reverse engineer what the system _does_ and then write tests for that. Of course you can ask people who are more familiar but whether you end up helping or being a distraction then is an open question.
- AlexCoventry 9y ago
  > whether you end up helping or being a distraction then is an open question. Ask on your team's IRC channel.
  - ljw1001 9y ago
    i hear you, but whether you get more than static depends on team/organization culture. It is good advice though.
galdosdi 9y ago
Start by adding a whole-system black box end-to-end test, if there aren't already any good ones. Ideally fully automated and automatically run for every commit via CI, but don't let the perfect be the enemy of the good, take what you can get for starters. Benefits: (1) You only really need to know the system as a user, not the codebase as well, to do this. (2) Well, #1 was a bit of a white lie. You'll end up finding out about all the (possibly undocumented) runtime dependencies this way, spinning up throwaway VMs and databases, etc. If the project is in production, this will be very useful knowledge, since you're probably the last point of escalation for strange prod issues. (3) Running this out of CI with throwaway VMs/containers will also force you to fully automate the install and make the damn thing actually work on a generic blessed OS configuration, which might be a huge boon to your team if you currently are in "Works on my machine" hell. I did this somewhere where we had tons of lost productivity because developers used OSX or Ubuntu on their workstations, but prod was RHEL, and the most fascinating deviations would be found by developers chasing the strangest of bugs. Making the install reproducible so we could have CI totally ended this. (4) If you don't have this already, and you set up infrastructure to gate commits on this test passing, team love and productivity will rapidly go through the roof as suddenly your developers aren't spending half their time fighting each other's build breaking changes. So yeah, it's just one thing, but it leads to so many benefits it's definitely where I would start. EDITED: Added an item to the list

I've had the same experience. I'm sure it's somewhat context dependent, but if the code amounts to business rules and they are not documented, which is very common, you can only reverse engineer what the system _does_ and then write tests for that. Of course you can ask people who are more familiar but whether you end up helping or being a distraction then is an open question.

AlexCoventry 9y ago
> whether you end up helping or being a distraction then is an open question. Ask on your team's IRC channel.
- ljw1001 9y ago
  i hear you, but whether you get more than static depends on team/organization culture. It is good advice though.

galdosdi 9y ago

Start by adding a whole-system black box end-to-end test, if there aren't already any good ones. Ideally fully automated and automatically run for every commit via CI, but don't let the perfect be the enemy of the good, take what you can get for starters. Benefits: (1) You only really need to know the system as a user, not the codebase as well, to do this. (2) Well, #1 was a bit of a white lie. You'll end up finding out about all the (possibly undocumented) runtime dependencies this way, spinning up throwaway VMs and databases, etc. If the project is in production, this will be very useful knowledge, since you're probably the last point of escalation for strange prod issues. (3) Running this out of CI with throwaway VMs/containers will also force you to fully automate the install and make the damn thing actually work on a generic blessed OS configuration, which might be a huge boon to your team if you currently are in "Works on my machine" hell. I did this somewhere where we had tons of lost productivity because developers used OSX or Ubuntu on their workstations, but prod was RHEL, and the most fascinating deviations would be found by developers chasing the strangest of bugs. Making the install reproducible so we could have CI totally ended this. (4) If you don't have this already, and you set up infrastructure to gate commits on this test passing, team love and productivity will rapidly go through the roof as suddenly your developers aren't spending half their time fighting each other's build breaking changes. So yeah, it's just one thing, but it leads to so many benefits it's definitely where I would start. EDITED: Added an item to the list