How to use TDD in a not very "Testy" environment

Question

I work in a company where OOP is... well, not fobidden, but at least frowned upon as "too complex". My coworkers write lots of 100+ lines functions and they are usually all in a "funcs.inc.php" or "something.inc.php", if they use any functions at all, often they don't since copy-paste is faster.

I would love to start using TDD at least for the code i write but as i have to interface with their code i can't see how to begin.

It's not legacy code as they are actively developing it and i don't want to modify their code as i don't want to provoke conflicts.

Which approach would you suggest, except for changing the company?

Answer 1

I've been in that position, both in an out of actual TDD. What I normally do is write tests for other people's interfaces, whenever possible. I then know before I run my code if they did one of the many common things that people do:

1. Broke an API by re-naming or completely doing away with something
2. Broke an API with subtle type changes that did not get noticed
3. Pushed a toxic revision without testing it
4. Sprung memory leaks (my test suite is Valgrind aware)
5. Block where they never blocked before

Any of those failing would usually result in me saying "Hey, can you check on (module), I think it broke in the last revision"

This got ugly only one time. Someone else got really upset that I was writing tests for their code and insisted that I was out for their job. I could not make the person understand that I was just out to make my job easier.

It's never a good idea to come right out and say "Look, I'm spending more time debugging your code than working on my own", unless you absolutely have to (i.e. your boss is asking about your performance). Most of the time, if you just send people the tests, they're happy to have them. If you're already meeting resistance with the idea, just try to not offend anyone or seem condescending.

Mock functions / stubs are ok, but what remains is the program as a whole is still likely to break if real tests aren't run. At least, when that happens, you can quickly rule out your stuff and (likely) point right at the problem.

Answer 2

Use TDD for all of your modules and write tests when you use their modules for something. Eventually, everybody else will notice that you produce high quality code much faster than anybody else and they will be curious as to why. That will be the perfect opportunity to educate them.

If they never ask, well, at least you made your life a little more easy.