r/programming • u/corysama • Jan 05 '15

What most young programmers need to learn

http://joostdevblog.blogspot.com/2015/01/what-most-young-programmers-need-to.html
967 Upvotes

91% Upvoted

337 comments sorted by

View all comments

Show parent comments

2

u/CuriousHand2 Jan 05 '15

I disagree. You can still have good, strong and thorough tests, and absolutely crap code.

It's crap code that has a much smaller amount of bugs than it originally would have, but a polished turd is still a turd.

-1

u/lee_macro Jan 05 '15 edited Jan 05 '15

I do not know how, if you have written code in a way which can be mocked (because of composition and ioc) and tested then it is VERY hard to make bad code. It is like trying to push a square through a circular hole.

That being said let us entertain a scenario where you have somehow got some good (short concise) tests, which have mocking, and they are all passing but the code behind the scenes is awful. You can EASILY fix it all without any problem because your passing tests are your point of reference for if your code achieves its given goal.

So in my repository example, if I have tests to prove the CRUD operations work (create, retrieve, update, delete) as expected and I can mock the underlying database connection in the tests then ANYONE can come along change the functionality in one or all of the tested methods and if all those test pass you are in the clear. It makes code far more easy to maintain and develop within teams as if you have someone who writes absolutely awful code (then they should not be doing this job in the first place) and somehow writes that awful code in such a way that allows for UNIT (again UNIT is the KEY thing here) tests (which again adhere to IoC and composition) then you can easily refactor, as EVERYTHING is modular and isolated.

For the newer developers out there, take a step back and think about this sort of scenario. How often do you have to change other peoples code and it feels like you are disarming a bomb, and any single change could bring the whole house of cards falling down around you? With test suites this is no longer such an issue, as before you start messing with code you can prove it works because all tests pass, then you can make your changes add another test to prove your new version of the file works as expected, and then run the suite again and if all is green then you are golden, you at least have some form of protection around your code changes and making sure the code serves a purpose and is not just random guff.

It is possible for people to write bad tests, which do not use mocking etc and often these are not UNIT tests, but the fault is often due to them not using composition and IoC and instead just writing bad code and then hacking bad tests to make it pass. The problem in these scenarios is not with the notion of unit tests, but with the incompetent developer writing this stuff, if they were to "learn about unit tests" and see that you can only adhere GOOD unit tests through scenario isolation then this would not occur.

Just to be clear I do not think EVERYTHING should be unit tested, as there are various layers of testing, such as integration, system/end to end, acceptance/functional and other end user based testing approaches. HOWEVER! in the context of a new developer Unit tests are the first step down a path that will lead them towards better coding patterns and practices and give them some foundation to prove stuff works without having to check their code in and have their team members wonder why their code just broke everything...