<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>positivecomment</author><text>&amp;gt;  as much as you can into static helper functions and most of the rest into dumb private stateless functions&lt;p&gt;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&amp;#x27;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 &amp;lt;&amp;#x2F;rant&amp;gt;). They just tell us to use IoC and move to the next point. I honestly don&amp;#x27;t know why. Our IoC library can treat a dependency as static or singleton, but those are also discouraged. Once I had a static class named GraphRequestHelpers* and the reviewer got really negative, FSM knows why. She told me that we need IoC to make everything testable and &amp;quot;Helper&amp;quot; in the name is a code-smell. Sounds cargo-culting to me but I have only 6 years of experience so who I am to know.&lt;p&gt;* Now we have RequestExtensions and everything is apparently perfect.</text><parent_chain><item><author>TeMPOraL</author><text>&amp;gt; &lt;i&gt;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.&lt;/i&gt;&lt;p&gt;The biggest problem I see with people advocating for tests and employing TDD is that they &lt;i&gt;do&lt;/i&gt; change how they write code to accommodate tests. This leads to inclusion of lots of unnecessary abstraction and boilerplate patterns that make code less readable and more bug-prone. OO world has spawned numerous non-solutions to turn your code inside-out so that it&amp;#x27;s easier to mock things, at the expense of code quality itself.&lt;p&gt;That said, if you go for functional style in OOP, i.e. shoving as much as you can into static helper functions and most of the rest into dumb private stateless functions, you suddenly gain both a clean architecture &lt;i&gt;and&lt;/i&gt; lots of test points to use in unit tests. So you can have testable code, but you have to chill out with the OOP thing a bit.</text></item><item><author>hinkley</author><text>Good lord.  Why integration tests?&lt;p&gt;&lt;pre&gt;&lt;code&gt;    I think the biggest thing you can do to write more integration tests is to just stop mocking so much stuff. 
&lt;/code&gt;&lt;/pre&gt;
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.&lt;p&gt;So they try to write E2E tests which work for about 5 or 6 quarters and then fall apart like a cheap bookcase. If you can find a new job before then, you never have to learn to write good tests!&lt;p&gt;I agree with the author that the trick is to stop using mocks all the time, but you don’t have to write integration tests to get rid of mocks. You have to write better code.&lt;p&gt;Usually if I have a unit test with more than one mock it’s bcause I’m too invested in the current shape of the code and I need to cleave the function in two, or change the structure of he question asked (eg, remake two methods into two other methods).&lt;p&gt;Almost always when I accept that the code is wrong, I end up with clearer code and easier tests.&lt;p&gt;Unit tests run faster, are written faster, and not only can they be fixed faster, they can be deleted and rewritten if the requirements change.  The most painful thing to watch by far is someone spending hours trying to recycle an old test because they spent 3 hours on it last time and they’ll be damned if they’re going to just delete it now.</text></item></parent_chain></comment><story><title>Write tests. Not too many. Mostly integration</title><url>https://blog.kentcdodds.com/write-tests-not-too-many-mostly-integration-5e8c7fff591c</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>hacker_9</author><text>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.&lt;p&gt;I practise TDD for peace of mind - if I add new functionality to existing code I can be 99.9% sure I haven&amp;#x27;t made any regressions. When a client&amp;#x27;s system goes down on a friday, I can 99.9% guarantee it wasn&amp;#x27;t my code that is at fault. If I have to work at the weekend to update a production server, I&amp;#x27;m 99.9% sure it&amp;#x27;ll go smoothly as my tests say it will.</text><parent_chain><item><author>TeMPOraL</author><text>&amp;gt; &lt;i&gt;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.&lt;/i&gt;&lt;p&gt;The biggest problem I see with people advocating for tests and employing TDD is that they &lt;i&gt;do&lt;/i&gt; change how they write code to accommodate tests. This leads to inclusion of lots of unnecessary abstraction and boilerplate patterns that make code less readable and more bug-prone. OO world has spawned numerous non-solutions to turn your code inside-out so that it&amp;#x27;s easier to mock things, at the expense of code quality itself.&lt;p&gt;That said, if you go for functional style in OOP, i.e. shoving as much as you can into static helper functions and most of the rest into dumb private stateless functions, you suddenly gain both a clean architecture &lt;i&gt;and&lt;/i&gt; lots of test points to use in unit tests. So you can have testable code, but you have to chill out with the OOP thing a bit.</text></item><item><author>hinkley</author><text>Good lord.  Why integration tests?&lt;p&gt;&lt;pre&gt;&lt;code&gt;    I think the biggest thing you can do to write more integration tests is to just stop mocking so much stuff. 
&lt;/code&gt;&lt;/pre&gt;
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.&lt;p&gt;So they try to write E2E tests which work for about 5 or 6 quarters and then fall apart like a cheap bookcase. If you can find a new job before then, you never have to learn to write good tests!&lt;p&gt;I agree with the author that the trick is to stop using mocks all the time, but you don’t have to write integration tests to get rid of mocks. You have to write better code.&lt;p&gt;Usually if I have a unit test with more than one mock it’s bcause I’m too invested in the current shape of the code and I need to cleave the function in two, or change the structure of he question asked (eg, remake two methods into two other methods).&lt;p&gt;Almost always when I accept that the code is wrong, I end up with clearer code and easier tests.&lt;p&gt;Unit tests run faster, are written faster, and not only can they be fixed faster, they can be deleted and rewritten if the requirements change.  The most painful thing to watch by far is someone spending hours trying to recycle an old test because they spent 3 hours on it last time and they’ll be damned if they’re going to just delete it now.</text></item></parent_chain></comment><story><title>Write tests. Not too many. Mostly integration</title><url>https://blog.kentcdodds.com/write-tests-not-too-many-mostly-integration-5e8c7fff591c</url></story>