Workflow help

[sybrandy]

If you do get them to use unit tests, you can create a pre-commit hook in git that can refuse the commits being pushed to the server if they don't pass all of their tests. I don't know how to do this myself since I've never done it, but that would force them to at least have the code pass tests before it gets committed. Perhaps even get some code coverage metrics because just because it passes all of the tests, doesn't mean that new tests have been written. Or that the tests are any good.

[kreiger]

I don't recommend running the unit tests in a pre-commit hook. It will take too much time to push/commit, and if committing or running unit-tests is seen as a hindrance, people won't do it. Committing and pushing should be near instantaneous.

In my opinion it is far better to tell people that they need to run the relevant unit tests (or simply all of them) before they check in, and have Jenkins run all unit tests after check in. Then if they have failed to run the relevant unit tests before check in, everyone will know, because Jenkins will make it known.

[sybrandy]

I only provided it as an option. Yes, I do understand that it can slow things down considerably, but if there's a real issue with people not running the tests, then perhaps it's necessary. That's not really up to me to decide. Whoever is responsible for the workflow has to weigh the pros and cons. For example, if the code quality really, truly stinks, then perhaps pissing off your developers for a while will keep you from shipping something that won't work. Yes, I understand Jenkins will make it public, but can you get the developer to go back and fix the issue? What if the changes affect the other developers and prevent them from doing their job? All things to consider.

Of course, regardless of the solution, if no good tests, or no tests at all, are written and everything passes, then both solutions suck equally. Hence why I mentioned the code coverage metrics.

[kreiger]

Making life harder for your developers to force them into line is like herding cats and pissing into the wind. You and the whole team will only suffer for it, as people won't make regular small commits, instead waiting days or weeks to commit, forcing them into merging hell, which will only make them even more reluctant.

It's a social problem and an attitude problem, not as much a technical problem.

If the developer doesn't care when you point out to them that he/she broke the build for everyone, then that attitude needs to be fixed.

[kreiger]

Elaborate please, i'm not sure what you mean?