Links to some of the other talks I referenced: Brian Ruth on Legacy Code: ua-cam.com/video/CktRuMALe2A/v-deo.html David Stone on building a custom vector: ua-cam.com/video/MfFzr9qqPDw/v-deo.html and ua-cam.com/video/I8QJLGI0GOE/v-deo.html (I thought my example was trivial. Nope! Wrong again...) Ansel Sermersheim & Barbara Geller on undefined behavior: ua-cam.com/video/NpL9YnxnOqM/v-deo.html ... and Chandler Carruth on the same topic: ua-cam.com/video/yG1OZ69H_-o/v-deo.html Fedor Pikus on Test-Driven Development: ua-cam.com/video/RoYljVOj2H8/v-deo.html I'm sure I've missed a few!
this talk sparked a couple interesting ideas for me: 1. the purpose of computing is automating labour 2. The reason I can watch this talk and understand the topic, while other people not working actively in the field may have a hard time grasping everything, is because we have different neurological graph topologies. Listening to some genre of music will activate some parts of their graph while it will be a different experience for me, because I have a different brain. And I'm just 18 minutes in. Came for tests and stayed for awe.
I have a nice example of tests that had negative value: the build pipeline was broken, so it turned out it was not rebuilding some tests, but running the old binary over and over. So they thought everything was ok, while tests were actually failing. Which eventually caused errors to reach the customer. Wrong information is worse than no information.
Which makes it all the more fun when Visual Studio pop's up a dialog when you launch the debugger and the build fails and ask: "The build failed, do you want to use the previously built binaries?". And to top it of it has a checkbox to not ask again, which is ticked by default, so if you say yes, you'll forever after be running the previous build if it fails to compile. I wonder which single user they asked before designing that UI, and why all the voices that has told them forever after has been ignored...
I’m teaching algorithms and data structures to students using C++ (yeah, they hate me). As I prepare the code almost from scratch, I stick to the plan A. TDD helps to find issues with interfaces I provide for students to implement. I was wondering what would I do if I get to work with the legacy code, the talk was helpful. Thank you.
30:00 Of course, capacity doesn't really matter. If it's not exposed, it's an implementation detail. If the problem is performance, then create a performance test instead. If you want to test it anyway here's a B2: consider allocation an external dependency, and inject (either locally or globally) a different (mock) malloc implementation that enables you to add expectations on behavior, this is what SetUp and TearDown are for. This probably works for most 3rd party code too.
24:31 "You wouldn't do this, we've already got one." Uh... gamedevs frequently do write their own specialized containers, including vector-like ones (especially "static vectors" that can guarantee that there are no heap allocations), because the standard containers don't do what we want. So this is a legitimate use case. :) Side note, plan A for gamedev has historically been "employ an army of low-paid manual testers" rather than automated tests. That is changing - slowly, and starting from the largest companies that can afford people to maintain CI infrastructure and test frameworks. Those ones tend to start with test frameworks that command the entire app automatically just as a manual tester would.
5:00 Couldn't find any talks by Fedor Pikus in 2017 in the back to basics category or on tests. I searched: Fedor, Pikus, back to basics, unit, test, there are no results that would be relevant for this talk. When I was writing this comment, I managed to find the talk. It's from 2019, search for "Back to Basics: Test-driven Development - Fedor Pikus - CppCon 2019".
Hi! Can someone explain to me what’s controversial about the talk from Fedor Pikus in 2019? Personally I have watched it several times and enjoy it but I would also like to know what people don’t like or agree with?
My hot take is not everything _should_ be unit tested. Greenfield dev you should write the module with a minimal public interface that can be easily mocked. Then write integration tests against a mock/fake system. Right now I'm testing an existing system with Golden Master Testing. The whole system is mocked with docker containers for the input ftp/sftp and output mysql.
6:38 "If you go back and watch Brian's talk from earlier this week..." There is no talk by Brian that has the same green lighting. Only about casting by Brian Rush "Back to Basics: Casting - Brian Ruth - CppCon 2021", it doesn't have same green lighting and it's about casting, not about legacy code problems. Can someone, please, give a name of the talk, if you know which talk by Brian Dave is talking about?
Links to some of the other talks I referenced:
Brian Ruth on Legacy Code: ua-cam.com/video/CktRuMALe2A/v-deo.html
David Stone on building a custom vector: ua-cam.com/video/MfFzr9qqPDw/v-deo.html and ua-cam.com/video/I8QJLGI0GOE/v-deo.html (I thought my example was trivial. Nope! Wrong again...)
Ansel Sermersheim & Barbara Geller on undefined behavior: ua-cam.com/video/NpL9YnxnOqM/v-deo.html
... and Chandler Carruth on the same topic: ua-cam.com/video/yG1OZ69H_-o/v-deo.html
Fedor Pikus on Test-Driven Development: ua-cam.com/video/RoYljVOj2H8/v-deo.html
I'm sure I've missed a few!
And, Titus Winters and Hyrum Wright: ua-cam.com/video/u5senBJUkPc/v-deo.html I stole some of their jokes because mine weren't as good. :-)
this talk sparked a couple interesting ideas for me:
1. the purpose of computing is automating labour
2. The reason I can watch this talk and understand the topic, while other people not working actively in the field may have a hard time grasping everything, is because we have different neurological graph topologies. Listening to some genre of music will activate some parts of their graph while it will be a different experience for me, because I have a different brain.
And I'm just 18 minutes in. Came for tests and stayed for awe.
I have a nice example of tests that had negative value: the build pipeline was broken, so it turned out it was not rebuilding some tests, but running the old binary over and over. So they thought everything was ok, while tests were actually failing. Which eventually caused errors to reach the customer. Wrong information is worse than no information.
This seems less an example for a negative value of tests but rather a showcase of negative value of bad CI implementation
Which makes it all the more fun when Visual Studio pop's up a dialog when you launch the debugger and the build fails and ask: "The build failed, do you want to use the previously built binaries?". And to top it of it has a checkbox to not ask again, which is ticked by default, so if you say yes, you'll forever after be running the previous build if it fails to compile.
I wonder which single user they asked before designing that UI, and why all the voices that has told them forever after has been ignored...
I’m teaching algorithms and data structures to students using C++ (yeah, they hate me). As I prepare the code almost from scratch, I stick to the plan A. TDD helps to find issues with interfaces I provide for students to implement. I was wondering what would I do if I get to work with the legacy code, the talk was helpful. Thank you.
30:00 Of course, capacity doesn't really matter. If it's not exposed, it's an implementation detail. If the problem is performance, then create a performance test instead. If you want to test it anyway here's a B2: consider allocation an external dependency, and inject (either locally or globally) a different (mock) malloc implementation that enables you to add expectations on behavior, this is what SetUp and TearDown are for. This probably works for most 3rd party code too.
24:31 "You wouldn't do this, we've already got one."
Uh... gamedevs frequently do write their own specialized containers, including vector-like ones (especially "static vectors" that can guarantee that there are no heap allocations), because the standard containers don't do what we want. So this is a legitimate use case. :)
Side note, plan A for gamedev has historically been "employ an army of low-paid manual testers" rather than automated tests. That is changing - slowly, and starting from the largest companies that can afford people to maintain CI infrastructure and test frameworks. Those ones tend to start with test frameworks that command the entire app automatically just as a manual tester would.
5:00 Couldn't find any talks by Fedor Pikus in 2017 in the back to basics category or on tests. I searched: Fedor, Pikus, back to basics, unit, test, there are no results that would be relevant for this talk.
When I was writing this comment, I managed to find the talk. It's from 2019, search for "Back to Basics: Test-driven Development - Fedor Pikus - CppCon 2019".
Hi! Can someone explain to me what’s controversial about the talk from Fedor Pikus in 2019? Personally I have watched it several times and enjoy it but I would also like to know what people don’t like or agree with?
Excellent content! Also, I was surprised with #define private public.
Phun question: A unit test don't depend on external data, but how then do you unit test a module who's sole task _is_ to fetch external data?
My hot take is not everything _should_ be unit tested. Greenfield dev you should write the module with a minimal public interface that can be easily mocked. Then write integration tests against a mock/fake system. Right now I'm testing an existing system with Golden Master Testing. The whole system is mocked with docker containers for the input ftp/sftp and output mysql.
Cracking talk :)
6:38 "If you go back and watch Brian's talk from earlier this week..."
There is no talk by Brian that has the same green lighting. Only about casting by Brian Rush "Back to Basics: Casting - Brian Ruth - CppCon 2021", it doesn't have same green lighting and it's about casting, not about legacy code problems.
Can someone, please, give a name of the talk, if you know which talk by Brian Dave is talking about?
@Dave Steffen has a comment on this video with a link to Brian Ruth's talk.
It’s not difficult. Start with the tests, not the UI.