|
|
|
|
|
|
by justinpombrio
2859 days ago
|
|
|
(c) and (d) are sensible suggestions, but I've got to question your (a) and (b). It sounds like you don't think much of testing, if you're expecting tests to be handed to you. Testing is hard! Writing good test cases can be as hard as writing the code itself. If your tests are inane, then you're going to catch the easy bugs and miss all the hard ones. And when on Earth do you get clear and detailed instructions on what is expected? At least in my current job, I feel like half of what I do is turn vague expectations into crisp technical requirements. If part of the assignment is for you to write a function, I can't include test cases for you because I don't know what type signature you're going to pick for the function. This isn't an inane detail. In some ways the signature of the function is more important than the implementation: the implementation is local to the function, but the signature is going to effect the structure of all of the code that uses it. |
|
|
Should have been clearer They should have tests to cover their code (not the code I'm going to right).. This cuts down on me adding testing libs needed, any setup, and laying down a pattern for their expectations(wrt tests). With expectation dev would add tests to cover their code.
> And when on Earth do you get clear and detailed instructions on what is expected?
On the job, I have easy access to the information/easy access to the people with the information. Not to mention personal relationships with the people I need to query.
My usage of 'inane' refers to things that a dev on the job won't be doing 99.9% of the time. Things that take effort & thought to setup(initial project setup) but don't really give any insight into whether a dev can write & architect code well. All the things a company already has in place.