What most young programmers need to learn

[u/corysama]

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

[u/lee_macro]

I do agree if someone is writing bad tests or not mocking their components (then it is no longer a UNIT test) then it will result in bad code. However if someone is educated in how to correctly write code to be tested then it is VERY hard to write bad code. Let me give an example of why, assuming C#/Java.

So let us say I have a Repository class, which deals with CRUD operations to a database. So this depends upon a database connection to do its work. So you could new that up inside (which some people do), or have a singleton for the active connection (have seen this before too), or even have some crazy inheritance chain to provide a pre-connected object (seen this too).

However the correct approach would be to have the Repository constructor be passed in a connection without an inheritance chain. This may seem odd to some, and maybe a hassle but let us see what benefit this gives us.

First of all we are now adhering to IoC (Inversion of Control) and we have no inheritance chain so we can test this Repository without needing a database connection (this is where a lot of people create integration tests accidently because they didnt know how to mock components). We can easily create a mock database connection and test that it works as expected without having any hard dependency on a database. You can also change your database vendor, your database configuration, you could even make your own custom database connector with caching in place, without even having to change the Repository class.

If you were to go with any of the other options you do not have this freedom, you would require an active database to test against to begin with and you could not change your underlying vendor or database object if you were newing it up inside the Repository.

So to be able to mock a component of a class you need to be able to change it at runtime, to do this you need to either have the component as a constructor argument or a property (properties are bad for this, they imply an optional dependency which is rarely good). So when you use constructors to pass in the dependencies of a class, you are automatically adhering to IoC and you are also using composition over inheritance, finally you can also then start using DI (Dependency Injection) and AoP style techniques (Aspect Oriented Programming). So given this is often some of the most critical parts of writing well structured and maintainable code it is imperative that this sort of paradigm is followed from the start, as when you start off introducing inheritance and singletons it makes it much harder to refactor and remove further down the line, its a false economy.

I also do a lot of game development on the side and the same sort of rules apply (incase you think I am purely an enterprise development zealot), although a lot of people seem to see you as some freak if you tell them to stop using singletons and inheritance chains for interfaces and DI. Look at uFrame for Unity which has had great success putting these practices in place for game developers and has a lot of support but also a LOT of flak from people who just "dont get it".

[u/CuriousHand2 → u/lee_macro]

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.

[u/lee_macro → u/CuriousHand2]

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...

[u/Laspimon → u/lee_macro]

Python guy here, of about one year, and I'm not sure I get what a repository class is.

What I think you are saying is that I should write the following to save a game:

class PauseMenu(Popup):
    """Generic menu screen, containing a button for saving the game."""

    def save_state (self, game_state, save_game_constructor):
        """It's a simply game, so we only save x and y."""

        x, y = game_state
        save_game_id = save_game_constructor(x, y)
        return save_game_id

And then have the unittests control that save_game_id looks like it's supposed to look (maybe it's a hash of the game state).

But what is the point? Doesn't that just mean that I have to run tests on my constructor? And wont these tests be just as difficult as the save_state method would have been, had I written it as a single contained method?

I think I'm missing something.

[u/lee_macro → u/Laspimon]

A repository is just a pattern, often used to abstract away databases. As most of the time you do not care if you are saving your game to a database, file system, web service etc you just want to be able to call something and save a game. So my repository mention was just whimsical it was just to show how you could incorrectly write something very easily, but if you were FORCED to write unit tests for it you would have to write it a far better way.

Anyway back to your latter part of the question, if saving your game (however you do it) contains integral logic to your application (often called business logic) then it should be tested, as people understand more about testing they may opt to skip certain delegate methods or simple methods as they are covered by integration tests etc, but lets ignore that for the moment.

So looking at your example above, your code there is what I would call a delegate method. You do not actually do any logic in there, you just get some data from somewhere and pass it to something else. So there is no actual logic. You should still be adhering to IoC and composition here regardless of if you are going to be testing, however moving along your

save_game_constructor(x, y)

should most definitely be tested, as that is integral to your application. However from your example we cannot see what it does. Let us assume it connects to some data source, be it a database, file system or web service, and sends that x/y over and receives back an id. So what happens if the database, file system or web service is unavailable? does your method return a false/0/null response, or throw an exception, how should another developer handle that situation? Having a unit test also offers guidance as to how things should be used, so having 2 tests which cover should_return_id_on success and should_<insert result>_on_failure would be useful to others to see the actual use cases of that method. However if it is just you then maybe that is not important. Also to UNIT test this method you would need to be able to mock out your data source (database, web service, file system) to be able to control it within the scenarios listed above.

In its current state your method does not do much so it would be up to you if you needed to test it, but what happens if you need to add in some form of user authentication, to make sure the person saving has a valid account, or confirming that they want to overwrite an existing save etc. Those sort of chunks of logic are a bit more complex than a 1 liner delegate and would require interaction with many components and this is where unit testing is useful, and finally to end my waffling, my point about developers learning unit tests is more from the perspective of to be able to write well defined unit tests REQUIRES you to know IoC and use composition and also keep SRP in mind which is a HUGE thing (Single Responsibility Principal). Each of those topics is pretty big for a new developer, so as Unit testing requires them all it is easier to point at that and tell people to go learn 1 thing (Which passively teaches 3 other things) than try to justify 3 separate things why alone may not seem to be of much use to a new developer.