Coding Horrors: You can gather all your technical debt into one easy framework!

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »

Linear Zoetrope: Nov 28, 2011; A hero must cook

fleshweasel posted:

At work we write unit tests for methods whose job is to call another method by mocking and making sure that the one method called the other method.

I feel a bit skeptical. My instinct is that stuff like that is implementation details and that behavior in terms of outputs and return values is what should actually be tested.

On one hand, I agree it seems a bit excessive. On the other hand, that is exactly the sort of thing where if it stops working for some reason it takes forever to find the bug.

# ? Aug 2, 2015 09:14

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 01:29

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

LeftistMuslimObama posted:

Some of the teams at my company do Agile or scrums or whatever, and it all seems so loving dumb to me. What's so hard about going to work, and doing the poo poo you need to do at a pace that enables you to meet your deadline? Why do we need special names and paradigms for everything? Just do as much work as you can at a reasonable pace every day. Don't stop until the work is done. The end. I have never organized myself further than "Monday I am doing a code review, Tuesday I'm going to focus on getting a rough version of Module Y knocked out... etc", and I am easily 3x more productive than any of the Agile devotees I've met at work, and I turn out a lot fewer bugs than them too. Half the Agile disciple teams aren't even allowed to do big enhancements right now because they have too many bugs to fix.

A lack of bugs is desirable, but it doesn't equal a product. If what you've described is really your attitude, god help you when upper management throws you demands that strain the resources of your team(?). If your idea of planning is "show up and work," you can expect to be either late or on death march.

# ? Aug 2, 2015 09:27

Linear Zoetrope: Nov 28, 2011; A hero must cook

I guarantee you, my 0 lines of code has fewer bugs than the competitor's product. Please give me money.

# ? Aug 2, 2015 09:30

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

LeftistMuslimObama posted:

Some of the teams at my company do Agile or scrums or whatever, and it all seems so loving dumb to me. What's so hard about going to work, and doing the poo poo you need to do at a pace that enables you to meet your deadline? Why do we need special names and paradigms for everything? Just do as much work as you can at a reasonable pace every day. Don't stop until the work is done. The end. I have never organized myself further than "Monday I am doing a code review, Tuesday I'm going to focus on getting a rough version of Module Y knocked out... etc", and I am easily 3x more productive than any of the Agile devotees I've met at work, and I turn out a lot fewer bugs than them too. Half the Agile disciple teams aren't even allowed to do big enhancements right now because they have too many bugs to fix.

You are vastly overestimating your productivity and underestimating those of your peers. Agile might not be the answer, but proper planning for features and requirements is definitely something you should practice.

# ? Aug 2, 2015 09:44

Athas: Aug 6, 2007; fuck that joker

Jsor posted:

I guarantee you, my 0 lines of code has fewer bugs than the competitor's product. Please give me money.

You're joking, but this is really the best way to minimise bugs and (more importantly) security issues. Minimise features and minimise complexity. In some cases, the additional complexity required to support dependency injection for so you can mock implementations for more isolated unit testing will result in a more complicated overall design, which invariably causes more bugs. It's not a simple tradeoff.

But always cut features all the time. It makes everything better.

# ? Aug 2, 2015 10:00

TheBlackVegetable: Oct 29, 2006

fleshweasel posted:

At work we write unit tests for methods whose job is to call another method by mocking and making sure that the one method called the other method.

I feel a bit skeptical. My instinct is that stuff like that is implementation details and that behavior in terms of outputs and return values is what should actually be tested.

I feel the same, tests are best targeted in terms of output. But if, for example, the method being called is one that would communicate with an external system - a database, an api, etc - then a mock of that call is testing output.

I wouldn't necessarily mock a method call that is simply a sub component of the logic being tested, but they have their uses.

# ? Aug 2, 2015 10:09

Mr Shiny Pants: Nov 12, 2012

Suspicious Dish posted:

but proper planning for features and requirements is definitely something you should practice.

This is true for almost anything.

We do get a bit buzzword heavy in IT.

# ? Aug 2, 2015 11:27

kitten smoothie: Dec 29, 2001

TheBlackVegetable posted:

I feel the same, tests are best targeted in terms of output. But if, for example, the method being called is one that would communicate with an external system - a database, an api, etc - then a mock of that call is testing output.

I wouldn't necessarily mock a method call that is simply a sub component of the logic being tested, but they have their uses.

Yeah, if the explicit outcome you want is that a method gets called on some dependency, then mock that out and confirm it happens.

But I've seen "tests" that basically end up walking through the internal logic and confirming various helper methods or w/e got called. At that point you're basically writing the same bugs into the test as you wrote into the implementation, and it's useless for checking your work when you change things later.

# ? Aug 2, 2015 14:55

Soricidus: Oct 21, 2010; freedom-hating statist shill

I can't believe people are coming out against mocking code in this of all threads

# ? Aug 2, 2015 15:02

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Mocks are frequently a perfect fit for this thread. Mocking everything is a great way to write a whole bunch of super brittle test code that doesn't even do a very good job of ensuring that the real code works correctly.

# ? Aug 2, 2015 15:27

NihilCredo: Jun 6, 2011; iram omni possibili modo preme:
plus una illa te diffamabit, quam multæ virtutes commendabunt

Plorkyeran posted:

Mocks are frequently a perfect fit for this thread. Mocking everything is a great way to write a whole bunch of super brittle test code that doesn't even do a very good job of ensuring that the real code works correctly.

:whoosh:

e: holy poo poo, there's no :whoosh: smiley yet? Quick, somebody go pay Lowtax $35 for the privilege.

# ? Aug 2, 2015 15:33

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

If you have to change the tests every time you make a change to a function, even if your change doesn't actually affect the thing that the test is nominally supposed to be testing, then it's straight-up a bad test. Lots of test code involving mocks ends up like this when written by people who don't quite get how it's supposed to work.

It also happens when you use a terrible mocking framework that requires you to specify the exact order of every function called on the mock instead of being able to just provide return values and only actually assert on the things that are relevant to the test.

# ? Aug 2, 2015 15:34

Thermopyle: Jul 1, 2003; ...the stupid are cocksure while the intelligent are full of doubt. �Bertrand Russell

Jabor posted:

If you have to change the tests every time you make a change to a function, even if your change doesn't actually affect the thing that the test is nominally supposed to be testing, then it's straight-up a bad test. Lots of test code involving mocks ends up like this when written by people who don't quite get how it's supposed to work.

It also happens when you use a terrible mocking framework that requires you to specify the exact order of every function called on the mock instead of being able to just provide return values and only actually assert on the things that are relevant to the test.

When I first starting unit testing my code years ago I wrote a lot of code like this. I feel like people don't really start writing good tests until they have to actually use tests to solve problems in their code and then all of a sudden they get it.

# ? Aug 2, 2015 15:37

baquerd: Jul 2, 2007; by FactsAreUseless

Thermopyle posted:

When I first starting unit testing my code years ago I wrote a lot of code like this. I feel like people don't really start writing good tests until they have to actually use tests to solve problems in their code and then all of a sudden they get it.

I agree completely. Really, writing tests is just committing what you are already doing mentally to a testing framework (unless you are some copy paste hacker I guess). A lot of code doesn't require thought and doesn't need testing, and writing fewer tests that test the right things is the way to create a really robust testing system that can stand change. Test business logic, test behaviors, test boundary conditions, but don't just test your loving code to make a coverage number go up.

# ? Aug 2, 2015 16:50

Edison was a dick: Apr 3, 2010; direct current only

Test your interfaces. If you're developing a library test its API. If you're developing an application test the observable behaviours.
Think very hard when you decide to test beneath an observable surface. It may still be worth it for core functions which are tricky, TDD for a subset of your codebase can be very useful.
Test what you want to happen, test what you don't want to happen if it's particularly awful.
Don't test the grey area in-between as you'll just be making brittle tests.

# ? Aug 2, 2015 17:13

qntm: Jun 17, 2009

C is for C and that's good enough for me.

C code:

int i;          /*  Signed */
signed int i;   /*  Signed, exactly the same meaning as the first one */
signed i;       /*  Signed, exactly the same meaning as the first and second one */
unsigned int i; /*  Unsigned */
unsigned i;     /*  Unsigned, same meaning as the one above */

char c;         /*  Signed or unsigned?  The standard says it could be either. */
signed char c;
unsigned char c;

# ? Aug 2, 2015 17:26

magnetic: Jun 21, 2005; kiteless, master, teach me.

LeftistMuslimObama posted:

Some of the teams at my company do Agile or scrums or whatever, and it all seems so loving dumb to me. What's so hard about going to work, and doing the poo poo you need to do at a pace that enables you to meet your deadline? Why do we need special names and paradigms for everything? Just do as much work as you can at a reasonable pace every day. Don't stop until the work is done. The end. I have never organized myself further than "Monday I am doing a code review, Tuesday I'm going to focus on getting a rough version of Module Y knocked out... etc", and I am easily 3x more productive than any of the Agile devotees I've met at work, and I turn out a lot fewer bugs than them too. Half the Agile disciple teams aren't even allowed to do big enhancements right now because they have too many bugs to fix.

I thought scrum was for the all of the team leads to get together regularly to get feedback from a user surrogate to keep the dev work relevant to the users evolving needs? A bunch of programmers getting together is a pretty huge waste of time, may as well be a coffee break.

# ? Aug 2, 2015 17:47

darthbob88: Oct 13, 2011; YOSPOS

magnetic posted:

I thought scrum was for the all of the team leads to get together regularly to get feedback from a user surrogate to keep the dev work relevant to the users evolving needs? A bunch of programmers getting together is a pretty huge waste of time, may as well be a coffee break.

My understanding is that it's a brief standup meeting where everybody gets together and plans out the day. "Adam's working on foo, but needs the bar that Boris is working on, and plans to have baz ready for Chang." The problem comes when managers forget that it's supposed to be a brief RPT BRIEF meeting, and puts everybody in chairs for three hours.

# ? Aug 2, 2015 17:52

loinburger: Jul 10, 2004; Sweet Sauce Jones

I had a manager who would add sixty minutes to scums by talking about golf

# ? Aug 2, 2015 18:01

Soricidus: Oct 21, 2010; freedom-hating statist shill

it's not a real scrum unless you're sticking your head between a couple of sweaty guys' butts and shoving the hooker as hard as you can

# ? Aug 2, 2015 18:06

IT BEGINS: Jan 15, 2009; I don't know how to make analogies

https://www.youtube.com/watch?v=URSWYvyc42M

This is a good watch - Sandi Metz explains very well what parts of your code you should and should not be testing. In short - test query results, direct command side-effects, and make sure outgoing commands are sent. Testing anything else (especially internal calls) will likely make your tests brittle/pointless.

# ? Aug 2, 2015 18:06

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

IT BEGINS posted:

https://www.youtube.com/watch?v=URSWYvyc42M

This is a good watch - Sandi Metz explains very well what parts of your code you should and should not be testing. In short - test query results, direct command side-effects, and make sure outgoing commands are sent. Testing anything else (especially internal calls) will likely make your tests brittle/pointless.

Yeah, that's why I never really understand using mocking frameworks and asserting that methods in the mocks are being called. The entire point of testing is that the mocked thing represents an implementation detail that I don't care about.

# ? Aug 2, 2015 19:15

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Mocking always struck me as more important for integration testing than unit testing.

# ? Aug 2, 2015 19:27

Plorkyeran: Mar 22, 2007; To Escape The Shackles Of The Old Forums, We Must Reject The Tribal Negativity He Endorsed

Uh, sort of the opposite. You aren't testing if things integrate correctly if you're mocking some of them.

# ? Aug 2, 2015 19:30

Blinkz0rz: May 27, 2001; MY CONTEMPT FOR MY OWN EMPLOYEES IS ONLY MATCHED BY MY LOVE FOR TOM BRADY'S SWEATY MAGA BALLS

Not sure I agree. If I'm integration testing a process I should be able to swap the implementation of whatever interfaces are being used in the process. As long as the mocks implement the interfaces then it shouldn't matter if the objects are real or fake.

# ? Aug 2, 2015 19:35

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

Blinkz0rz posted:

Not sure I agree. If I'm integration testing a process I should be able to swap the implementation of whatever interfaces are being used in the process. As long as the mocks implement the interfaces then it shouldn't matter if the objects are real or fake.

You're not testing that the actual implementations integrate correctly if you use a mock. You can certainly still use mocks in an integration test if you only want to validate the integrated behavior of a subset of your dependencies, but if you mock all of the dependencies, it's no longer an integration test.

# ? Aug 2, 2015 19:40

IT BEGINS: Jan 15, 2009; I don't know how to make analogies

Ithaqua posted:

Yeah, that's why I never really understand using mocking frameworks and asserting that methods in the mocks are being called. The entire point of testing is that the mocked thing represents an implementation detail that I don't care about.

I think it's important to test that the methods are being called, but not what the results of those methods actually are. That said, it's only important for commands, as testing the external collaborators of queries is the same as testing the internals of queries, which is bad.

I think part of the confusion also stems just from misunderstanding which is which in the mock vs. stub vs double, especially since they are sometimes used interchangeably.

# ? Aug 2, 2015 19:41

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

IT BEGINS posted:

I think it's important to test that the methods are being called, but not what the results of those methods actually are. That said, it's only important for commands, as testing the external collaborators of queries is the same as testing the internals of queries, which is bad.

I think part of the confusion also stems just from misunderstanding which is which in the mock vs. stub vs double, especially since they are sometimes used interchangeably.

If I'm testing the behavior of Foo that has a dependency on IBar and I create an IBar mock, I don't care what Foo does with IBar. For all I care, it could do nothing at all with it -- my overriding concern is that when I call a method in Foo, that method gives me back the data I'm after. Validating that a method in the mock implementation of IBar is called is just giving me a reason for a test of Foo to break when I refactor IBar.

If IBar causes some sort of side effect somewhere else in the class that has to be validated, that makes me think I'd better have a test explicitly for that side effect... not an assertion that the method that causes the side effect is being called.

New Yorp New Yorp fucked around with this message at 19:54 on Aug 2, 2015

# ? Aug 2, 2015 19:51

ultramiraculous: Nov 12, 2003; "No..."; Grimey Drawer

Soricidus posted:

I can't believe people are coming out against mocking code in this of all threads

# ? Aug 2, 2015 19:52

IT BEGINS: Jan 15, 2009; I don't know how to make analogies

Ithaqua posted:

If I'm testing the behavior of Foo that has a dependency on IBar and I create an IBar mock, I don't care what Foo does with IBar. For all I care, it could do nothing at all with it -- my overriding concern is that when I call a method in Foo, that method gives me back the data I'm after. Validating that a method in the mock implementation of IBar is called is just giving me a reason for a test of Foo to break when I refactor IBar.

Ah, agreed. I misunderstood what you meant before.

Re: bad scrum and why you might need it - beyond small companies or small teams, it's very useful to start organizing your dev process. Not every company can afford to have every dev come in and 'just do some work', even if they are great devs that are extremely productive. My company is running into this sort of issue right now - we've been using the 'just work on module X today' method for a long time and now that we get larger projects and larger features we really need a good way of keeping everyone up to date on what is being worked on and whether or not the project as a whole is on schedule.

# ? Aug 2, 2015 19:57

New Yorp New Yorp: Jul 18, 2003; Only in Kenya.; Pillbug

IT BEGINS posted:

Re: bad scrum and why you might need it - beyond small companies or small teams, it's very useful to start organizing your dev process. Not every company can afford to have every dev come in and 'just do some work', even if they are great devs that are extremely productive. My company is running into this sort of issue right now - we've been using the 'just work on module X today' method for a long time and now that we get larger projects and larger features we really need a good way of keeping everyone up to date on what is being worked on and whether or not the project as a whole is on schedule.

Companies jump on the bandwagon without understanding what the bandwagon really is, or without buy-in and understanding from upper management. They end up practicing what is affectionately called agilefall (or waterscrum, or scrummerfall, or whatever). It has all of the downsides of waterfall and all of the downsides of agile, with none of the upsides of either, in one neat package. There's no documentation or project plan, tons of pointless, long meetings, and the PO/PMs feel free to change priorities and tasks with no warning.

That said, it's fine to modify the process as long as the modifications are being made for good, thought-out reasons and that the process changes have full buy-in from the top down. You just get a lot of "the devs want to do scrum, but no one at any level higher than a team lead wants to do it, so we'll just have a totally insane, bastardized process that doesn't work well for anyone"

# ? Aug 2, 2015 20:18

Gazpacho: Jun 18, 2004; by Fluffdaddy; Slippery Tilde

I'm all for unit testing, and TDD as a means of ensuring that tests get written, but I also agree with the critiques of Robert Martin, who promotes his methods as a substitute for expertise � as if two fools with the proper testing discipline could reconstruct computer science and design patterns from scratch.

# ? Aug 2, 2015 20:58

Jabor: Jul 16, 2010; #1 Loser at SpaceChem

An example of good use of mocking is when the "side effect" of one of your methods is that a network request is made - you want to put a mock into the chain at some point and check that the unit being tested issues the request. You don't want to let the request happen and then check the network logs or something to see if the request happened - that's suitable for an integration test, not a unit test.

In general, if a component breaks, both the tests for that component and your overall integration tests should start failing. But your unit tests for other components should keep passing - if you integrate a large change and suddenly the entire world is failing, it's a lot harder to figure out what the problem is compared with if you integrate the change and your integration tests + networking unit tests start failing.

# ? Aug 3, 2015 03:13

AWWNAW: Dec 30, 2008

Ithaqua posted:

Companies jump on the bandwagon without understanding what the bandwagon really is, or without buy-in and understanding from upper management. They end up practicing what is affectionately called agilefall (or waterscrum, or scrummerfall, or whatever). It has all of the downsides of waterfall and all of the downsides of agile, with none of the upsides of either, in one neat package. There's no documentation or project plan, tons of pointless, long meetings, and the PO/PMs feel free to change priorities and tasks with no warning.

I've never seen "Agile done right" but I've seen a whole lot of this. "Management" picks the parts that suit them: time tracking, daily status meetings, feature tracking, micromanagement, etc., throws the rest away and calls it Agile; because if you're not doing Agile, you're doing Waterfall, and that's bad. It's just become a banner to wave, and I think one of the authors of the original "manifesto" even came out and said so recently.

# ? Aug 3, 2015 03:54

Steve French: Sep 8, 2003

Ithaqua posted:

If I'm testing the behavior of Foo that has a dependency on IBar and I create an IBar mock, I don't care what Foo does with IBar. For all I care, it could do nothing at all with it -- my overriding concern is that when I call a method in Foo, that method gives me back the data I'm after. Validating that a method in the mock implementation of IBar is called is just giving me a reason for a test of Foo to break when I refactor IBar.

If IBar causes some sort of side effect somewhere else in the class that has to be validated, that makes me think I'd better have a test explicitly for that side effect... not an assertion that the method that causes the side effect is being called.

Say that Foo is some thing with some business logic, and IBar is some form of datastore that Foo writes to. Your unit tests for Foo surely shouldn't care whether the particular backing implementation of IBar is Redis, or Postgres, or Cassandra; but you do want to ensure that when you are expecting a call to a method on Foo to write something to the datastore, that that call happens. You don't tie the unit test for Foo to one specific implementation of IBar, and check that a row appears in the database or whatever. You test what Foo is supposed to do using a mock IBar, you have separate tests for each implementation of IBar that actually verify that when a call to write something to the datastore is made, that the write happens, and then you have integration tests that verify everything works when put together at a higher level.

# ? Aug 3, 2015 03:55

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

AWWNAW posted:

I've never seen "Agile done right" but I've seen a whole lot of this. "Management" picks the parts that suit them: time tracking, daily status meetings, feature tracking, micromanagement, etc., throws the rest away and calls it Agile; because if you're not doing Agile, you're doing Waterfall, and that's bad. It's just become a banner to wave, and I think one of the authors of the original "manifesto" even came out and said so recently.

This paper? https://gist.github.com/joshwand/710960

# ? Aug 3, 2015 03:58

Suspicious Dish: Sep 24, 2011; 2020 is the year of linux on the desktop, bro; Fun Shoe

though lmao at "In the end, Royce proposed a far more nuanced and insightful approach, leaving the reader to giggle at the silliness of the �grandiose� model."

here's what Royce proposed, on the left, in contrast to Waterfall, on the right

# ? Aug 3, 2015 04:00

AWWNAW: Dec 30, 2008

Suspicious Dish posted:

This paper? https://gist.github.com/joshwand/710960

This blog post actually: http://blog.toolshed.com/2015/05/the-failure-of-agile.html

# ? Aug 3, 2015 04:02

Soricidus: Oct 21, 2010; freedom-hating statist shill

Suspicious Dish posted:

though lmao at "In the end, Royce proposed a far more nuanced and insightful approach, leaving the reader to giggle at the silliness of the �grandiose� model."

here's what Royce proposed, on the left, in contrast to Waterfall, on the right

No arrow between testing and operations, looks about right

# ? Aug 3, 2015 07:48

Adbot: ADBOT LOVES YOU

# ? Jun 1, 2024 01:29

qntm: Jun 17, 2009

Suspicious Dish posted:

though lmao at "In the end, Royce proposed a far more nuanced and insightful approach, leaving the reader to giggle at the silliness of the �grandiose� model."

here's what Royce proposed, on the left, in contrast to Waterfall, on the right

I like that one of the distinguishing features of Waterfall, over Royce's model, is that in Waterfall you can go back and redo steps.

# ? Aug 3, 2015 10:23

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Coding Horrors: You can gather all your technical debt into one easy framework!

«‹›1503 »