Earlier quoted context omitted.
> as much as you can into static helper functions and most of the rest into dumb private stateless functions In our work we use C# and it is very hard, even next to impossible to make a static class pass a code review - given it's not for extension methods (which I hate... why not be explicit about the first parameter and stop acting as a part of the class ). They just tell us to use IoC and move to the next point. I…
Could someone expand IoC for me please?
Write tests. Not too many. Mostly integration
91–100 of 338 posts
Re: Write tests. Not too many. Mostly integration
#92Earlier quoted context omitted.
The abstraction is consistent though, and familiarity is a good thing when navigating a codebase which has N amount of other devs pushing to it every day. I practise TDD for peace of mind - if I add new functionality to existing code I can be 99.9% sure I haven't made any regressions. When a client's system goes down on a friday, I can 99.9% guarantee it wasn't my code that is at fault. If I have to work at the weeke…
Exactly this. Confidence is everything. I can actually write entire features with appropriate test coverage from the ground up and they work first time and have close to zero defects in production. It's amazing when you spend 5-6 days writing code that does nothing and at the last moment, everything slots together with a few integration tests and wham, feature done. Not talking trivial stuff here either; big integrat…
How do you deal with http interactions in test? Do you mock it or maybe save it to disk to replay later?
Re: Write tests. Not too many. Mostly integration
#93Earlier quoted context omitted.
Do you practise TDD? If you did a lot of this would make more sense to you. TDD is actually quite fun when you get the hang of it (less mental burden as you push all the 'intent' onto the computer).
I don't see why TDD requires ruling out static methods and insisting on hiding everything behind an interface. Static methods are straightforward to test, certainly more than a class with multiple dependencies which need to be mocked. Usually the complaint is about coupling when calling static methods but these can be wrapped in a delegate if required.
Problem is that the moment you start introducing delegates and crap like that is you're inventing a mechanism to work around your resistance to not using static methods rather than actually solving any problems.
There is no functional difference between a class with static methods and a class without, of which one instance is available to other classes.
Other than the fact that it isolates state, allows mocking and substitution and testing.
Re: Write tests. Not too many. Mostly integration
#94Good lord. Why integration tests? I think the biggest thing you can do to write more integration tests is to just stop mocking so much stuff. Okay. The biggest problem I see with people trying to write unit tests is that they don’t want to change how they write code. They just want tests for it. It’s like watching an OO person try their hardest to write OO code in a functional language. So they try to write E2E tests…
> The biggest problem I see with people trying to write unit tests is that they don’t want to change how they write code. They just want tests for it. It’s like watching an OO person try their hardest to write OO code in a functional language. The biggest problem I see with people advocating for tests and employing TDD is that they do change how they write code to accommodate tests. This leads to inclusion of lots of…
> unnecessary abstraction and boilerplate patterns
That means you didn't actually change the code. It means you added unnecessary abstractions around your code in order not to change it.
Unit tests guide you towards simplicity. In my experience, the only times they haven't done that is when I have made some assumptions about what the code should be and not allowed the tests to drive me towards that simplicity.
Re: Write tests. Not too many. Mostly integration
#95Earlier quoted context omitted.
This is true. Areas where I have full unit test coverage tend not to have any bugs. What a waste of time to have written all these tests!
I assume you are sarcastic, but cannot figure out what your actual point is. Are you disputing integration tests can find some types of errors which unit testing will not uncover?
I read your comment "Because they can find bugs and errors which unit tests cannot." to suggest that unit tests cannot find bugs.
You probably meant "Because they can find bugs and errors that unit tests cannot." to remove the ambiguity.
tl;dr, I am illiterate; but a little change to the original comment could make it easier.
Re: Write tests. Not too many. Mostly integration
#96Earlier quoted context omitted.
> as much as you can into static helper functions and most of the rest into dumb private stateless functions In our work we use C# and it is very hard, even next to impossible to make a static class pass a code review - given it's not for extension methods (which I hate... why not be explicit about the first parameter and stop acting as a part of the class ). They just tell us to use IoC and move to the next point. I…
Could someone expand IoC for me please?
[deleted]
Re: Write tests. Not too many. Mostly integration
#97Earlier quoted context omitted.
> The biggest problem I see with people trying to write unit tests is that they don’t want to change how they write code. They just want tests for it. It’s like watching an OO person try their hardest to write OO code in a functional language. The biggest problem I see with people advocating for tests and employing TDD is that they do change how they write code to accommodate tests. This leads to inclusion of lots of…
> as much as you can into static helper functions and most of the rest into dumb private stateless functions In our work we use C# and it is very hard, even next to impossible to make a static class pass a code review - given it's not for extension methods (which I hate... why not be explicit about the first parameter and stop acting as a part of the class ). They just tell us to use IoC and move to the next point. I…
There is some cargo culting there but it's mostly correct.
Helper is a code smell as it's a sign of "we don't know what the responsibility of this is or what to call it so we'll just chuck a load of shit in this file and call it a helper". The methods in should belong to something and live on that class, not in an external class.
RequestExtensions is more shit than the original solution. Extension methods are even worse! Shoot the reviewer.
Re: Write tests. Not too many. Mostly integration
#98Good lord. Why integration tests? I think the biggest thing you can do to write more integration tests is to just stop mocking so much stuff. Okay. The biggest problem I see with people trying to write unit tests is that they don’t want to change how they write code. They just want tests for it. It’s like watching an OO person try their hardest to write OO code in a functional language. So they try to write E2E tests…
> The biggest problem I see with people trying to write unit tests is that they don’t want to change how they write code. It’s like watching an OO person try their hardest to write OO code in a functional language.
I personally hate javascript with the burning passion of a thousand suns. I just can't stand it. I can't stand the syntax, the philosophy, the package manager, the idea of "lets not worry about how X work just do an include and npm install", the abyss that is the error system, the person who considered 'undefined' to be a good thing to implement, the NaN that has nothing to do with numbers but everything to do with type casting when there is no actual type system, the lack of a good standard library, the fragmentation and slow progression of the language, the callback hell, the coercive nature of it's operators when you don't expect them to, the 6000 ways you can make an "object" that is not really an object, the confused terminology that goes against every other agreed-upon language, the myriads of outdated tutorials that lead developers to copy/paste code that stopped working 10 years ago, the notion that javascript is sexy and ES6 fixed it, the fact that you (whoever reads this) think you fixed it, the godawful bloated frameworks, the fact that I need 14000 dependencies to run a simple project because every 2 lines require their own implementation of a github repo so that the developer can boast about his cool profile, and most of all I hate the person who thought it would be a good idea to take this mess and put it server side.
I can put almost all of that aside and work through threw whatever is thrown at me. However, what I can't ignore is when a language is deceptive by nature. Ex. Javasript uses the term "object" to describe something that isn't an object in the traditional sense. Hence when an OO person tries to write OO code in said language they end up getting virtually molested by whoever designed said functionality mainly because the OO person expects things to work in a certain way when they don't due to naming.
The problem is not them not adapting and changing how they write code; the problem is actually the language itself being designed by retarded monkeys who confuse terminology and at the same time don't communicate the reasoning behind their decision making. Hence what you get is someone like myself who spends hours pulling his hair out trying to figure out why there is nothing similar to an isset() function in the standard library or why '2 == [[2]]' or why JS adds a ';' at the end of EVERY LINE. I mean Just look at this:
function mynum() { return 1; }
console.log(mynum()); // undefined
I would submit to you that most OO people would have an easy time transition to ANY functional language that isn't designed to confuse because before we ever did OO, all of us did functions and can easily reason about them and how they relate to each other. The problem is the language, not the user!
Re: Write tests. Not too many. Mostly integration
#99Earlier quoted context omitted.
I don't see why TDD requires ruling out static methods and insisting on hiding everything behind an interface. Static methods are straightforward to test, certainly more than a class with multiple dependencies which need to be mocked. Usually the complaint is about coupling when calling static methods but these can be wrapped in a delegate if required.
Simply because you can't mock the static dependency, therefore that method is now dependent on the static class and you don't have any control over it. This is problematic - what if at some point later another developer adds a database call into the static method to do some logging? Now your testing will dirty whatever database you're using, as well as run 10x slower - and yet the test will still pass and everyone wi…
> that method is now dependent on the static class and you don't have any control over it.
I don't see how you have any less control over it than any other code you wrote. If you don't want it to write log statements, then don't do that. Most static methods are small and pure so don't need to write log statements anyway.
> Now your testing will dirty whatever database you're using, as well as run 10x slower.
I've never used a logging framework that didn't allow you to configure where log statements were written, or give you control over the logging threshold for individual classes. However if your method is writing logs then presumably there is a reason, which is just as useful in the tests. If you mock it out then you're testing against different code to the one you will actually run against.
> If you start using a custom delegate solution, then your code is not consistent with everything else that uses DI.
Passing functions as arguments directly is 'DI', just without the need to configure that through an external container. Reducing the amount of interfaces (often with a single implementation) and external configuration makes navigating the code easier.
Re: Write tests. Not too many. Mostly integration
#100Earlier quoted context omitted.
Exactly this. Confidence is everything. I can actually write entire features with appropriate test coverage from the ground up and they work first time and have close to zero defects in production. It's amazing when you spend 5-6 days writing code that does nothing and at the last moment, everything slots together with a few integration tests and wham, feature done. Not talking trivial stuff here either; big integrat…
How do you deal with http interactions in test? Do you mock it or maybe save it to disk to replay later?
That's an integration test really. The clients all have an abstraction around the http endpoints so nothing touches integration in unit tests. The advantage of this is you deal with transfer objects only in the code, no HTTP which would violate separation of concerns.
I use HttpMock myself in test cases which fires up an http server for personal projects. We use Wiremock commercially.