3 ms·
The code that is more easily unit testable, is the code I care about. Neither example is easily tested. Neither support injecting the dependencies, which make
by latchkey 3y ago
The code that is more easily unit testable, is the code I care about.
Neither example is easily tested.
Neither support injecting the dependencies, which make mocking really difficult.
On the left, you're testing one big method with a whole bunch of conditionals, which leaves you with a whole ton of tests for that one big method.
On the right, there is a bake() method and it does oven.New(), but where does oven come from? Is it some global somewhere?
- jpc0 3y agoHere is an idea for a unit test for this code. Pass in an order, assert the pizza that comes out is correct. The entire function is a unit which can fit on my phone screen and has no external dependencies other than possibly oven, which was discussed in the article, it should probably have been passed in, aka dependency injection.
- latchkey 3y agoSince the example was golang, I personally love uberFX to define modules and dependencies between modules. When you do it that way, unit tests become really easy. It isn't necessary with golang to do this at all, but it really helps build consistent structure throughout the entire app, so I do it. Speaking from personal experience. I built a small golang process that ran on around 25k worker machines. It had to be bug free cause if it crashed and stopped running, it meant updating a whole lot of computers across multiple data centers, by hand. We unit tested everything and the project worked out really well because of that.
- deleted 3y ago[deleted]
- anon-3988 3y agounit test is overrated because most of the problems can be solved via correct by construction methods. Like, do you really need to check if this "kind" variable is equal to "Veg"? This could have easily been solved by using Enum. Similarly, global or not can be solved by using classes/structs that don't have any constructors or something like that. Functions should exist at the level of concepts: 1. arr | flat | map | collect as HashMap makes sense. 2. CreateFlattenMappedHashMapFromArr does not.
- xmcqdpt2 3y agoAgree. Furthermore if you are going to split it, you want to make sure no one boxes a raw pizza because they added a bad switch statement or something, as that would be clearly bad. So if you want a split version than you should use types to mark the transitions between states. boxPizza should take a CookedPizza, and BakePizza should take a RawPizza and return a CookedPizza etc.
- bazoom42 3y agoBoth functions take an order and return a pizza. This seem perfect for testing. Why would you care where the oven comes from, if the function deliver perfectly baked pizza? A unit test should test against the public interface and not be coupled to implementation details, since that will hamper refactorings. > which make mocking really difficult. Mocking is an antipattern anyway, and should be avoided except for nondeterministic components like current time or stateful external services.
- latchkey 3y ago[flagged]
- hbrn 3y agoApologies, but such mindset is the essence of the worst programming traits. > The code that is more easily unit testable, is the code I care about. Author argues that his code is more readable. Sounds like you're saying that being unit-testable is more important than being readable. > Neither example is easily tested. Only if you're a unit testing zealot. Integration/E2E testing is easy for both. > Neither support injecting the dependencies, which make mocking really difficult. Mocking is not a virtue. Also, if mocking is the sole reason you're using DI, you're doing it wrong.
- latchkey 3y agoArguing for unit testing, is the worst? Come on, look in the mirror.