Tap to unmute

Jonathan Blow on unit testing and TDD

  Рет қаралды 139,501

Jeru Sanders

Jeru Sanders

Күн бұрын

Пікірлер: 311
@MrOhioutod
@MrOhioutod 5 жыл бұрын
Jon Blow: "Don't take me out of context, testing is very important, right? If you don't test your software, then your software doesn't work. What I'm saying is, I don't think that this obsessive unit testing that happens in many cases is the right way to test. I think there are more efficient, better ways to test that capture more bugs. And we want to do those things." That's a very different statement than what most people are criticizing.
@KayraAlat
@KayraAlat 4 жыл бұрын
Explaining what the better ways to test are would probably help his argument
@ShawnBlais
@ShawnBlais 3 жыл бұрын
@@KayraAlat He does. Higher level integration tests that test many systems at once, and are much more likely to surface bugs that occur at the interaction points between systems.
@megabyte01
@megabyte01 2 жыл бұрын
...come to think about it, one wonders if the shops that advocate for unit testing need it because they are also ones with higher turnover? Hear me out. When a project goes on for a while, it's inevitable that people will come and go, and they take their understanding of the code with them. Sometimes they write good documents or even good code that is easy to follow. If not, then unit-tested is easier to work with. Still, you can't register morality or professionalism
@DF-ss5ep
@DF-ss5ep 2 жыл бұрын
@@megabyte01 Maybe that's true, but more practical tests, like integration tests, do the same thing, and better. The problem is that they're harder to make, and maybe that's related - if there's high turnover, there will probably be more beginner programmers, and those beginner programmers can't write integration tests. But management feels things slipping away, so they either want to have documentation like you said, or they want more control, so they force developers to write tests, and unit tests are the only tests they can write, or the only tests they are trusted to write (I've been in these companies, and one thing that jumps out a lot is a lack of trust in the developers' ability to think, so work has to always fit within strict moulds; this leads to brain dead unit tests that sometimes not even test anything).
@megabyte01
@megabyte01 2 жыл бұрын
@@DF-ss5ep you're not wrong about integration tests like JBehave being difficult to write. You basically have to build a whole other project to test the one you're standing up. They take more time and resources than unit tests to check the same basic functionality. Still, those Integration tests were worth the effort because they caught bugs we never would have thought of. Some things just don't show up in your frictionless mock classes. They also let us know when other teams made changes that would have broken our services.
@theb1rd
@theb1rd 4 жыл бұрын
If you've watched Jon working on his compiler, you've seen that he runs a battery of "unit tests" after significant changes, he's just not religious about it. There's a point of diminishing returns, which dogmatists proudly ignore.
@prologik85
@prologik85 4 жыл бұрын
I hate dogamtisms like SOLID for example. TDD, DDD are other examples about this bulshit tech companies invent to add more costs to their software, costs who are putted on the investors's pocket.
@hasen_judi
@hasen_judi 4 жыл бұрын
These are NOT "unit" tests. You are confusing "unit" testing for "automated" testing.
@rubberduck2078
@rubberduck2078 3 жыл бұрын
Those are whole program tests, not unit tests
@tannerted
@tannerted 2 жыл бұрын
Those are more like integration tests, meaning instead of testing individual units, they test the output of various units working in tandem.
@romaingauthier2653
@romaingauthier2653 5 жыл бұрын
To be fair about pair programming: I used to know a company that would d pair programming for all juniors and mid-level programmers, while the founders (guys who started in the 80s and were all killers) would program solo. They found that their less experienced programmers would produce higher quality code and improve faster when working in pairs. It seemed to work for them. This wasn't a game company by the way, but an AI company.
@tech6hutch
@tech6hutch 4 жыл бұрын
I'd love to work directly with a more senior programmer. I feel like I've learned the most from working with people with more experience than me. And, of course, I'm sure my presence would help a junior programmer write better code and learn my thought process when writing code.
3 жыл бұрын
University of Utah study showed a 15% overall benefit to pair programming. Whether their method took "costs seriously" is debatable I guess.
@davidboreham
@davidboreham 2 жыл бұрын
If "pair programming" is really "training junior developers" that's totally fine. But let's call it that.
@Czeckie
@Czeckie 2 жыл бұрын
gonna defend pair programming (not training the juniors): my friend is a leader of a small team, during covid and remote work he tried to boost moral by group activity coding. Basically one person shares their screen and the others are discussing the project. Sometimes they even dictate the code they would write. Does that sound tedious? Turns out they became more productive, everyone knows and understand their codebase, people have fun, are having friendlier relationships, etc. What started as an experiment activity became their main dev process. People still have individual singular tasks, but anything more complicated is done like this. The productivity gain can be explained partly by psychology (rubber duck sort of thing), but one aspect is that they don't have to rewrite much. They collectively arrive at the solution easier, see potential problems early and so one. Sure, maybe this could have been probably achieved by having senior "killers" devs, but you have to work with what you have.
@asdqwe4427
@asdqwe4427 2 жыл бұрын
Yes, pair programming is a solid way to teach
@willmcpherson2
@willmcpherson2 5 жыл бұрын
For me, testing is something that grows naturally, like any other part of the program. You start with a dumb program, manual compilation and manual testing. Over time your program takes form, your build system becomes more sophisticated and you develop an automated test suite.
@bigmofo1122
@bigmofo1122 7 жыл бұрын
Asking Jonathan Blow about unit testing is a meme at this point.
@wombologist1377
@wombologist1377 4 жыл бұрын
Part of the problem is that we adopt these strategies with an all-or-nothing mentality, when the best way to go is adopt as needed. All these mentalities give people false sense of security - we feel good in "believing" in something like a religion.
@Elrinth
@Elrinth 4 жыл бұрын
@ 05:40 -> Pair programming is about sharing the knowledge of the code. Not become more efficient. It's never going to be more or of equal efficiency. But he is totally correct, it's all about costs. Very nice talk, and nice hearing his opinion.
@DagarCoH
@DagarCoH 2 жыл бұрын
I disagree. In my experience it is also more efficient unless the two participants each have a very good day. If one or both of the participants are not on their prime that day, it does boost the overall productivity. Two immediately clear aspects are that 1) you talking through the problem with someone and reasoning about it tends to lead to a more efficient, elegant, readable and/or scalable solution than doing it alone (and that even works if you talk about it with someone not understanding a word of it, but is great if the two are on the same line), and 2) it helps get over the bump of "a new big problem, I am in over my head and don't know where to start", because divide and conquer comes totally natural when you talk about what needs to be done.
@MechMK1
@MechMK1 2 жыл бұрын
I remember being an intern in a company, and I was brought along to a discussion regarding unit tests. And the manager wanted unit tests for *everything*. Like, every tiny bit of code had to be tested obsessively, to the point where trivial functions (like getters and setters) needed unit tests. The programmers complained, saying that they will end up spending countless hours writing code, which ultimately never get any value to the customer. The discussions after the meeting were very insightful, because they essentially drove the point home "test where it matters". Like, if you have some complex business logic, make sure that there are tests for that. If you have some code, that writes files into a specific format, make sure that the data produced by those functions adheres to the specified format. But everything else? It doesn't matter. What really opened my eyes was "You don't need to test whether or not some internal logic works. If it doesn't, then that will result in some observable failure - and *that* is what you should test for." Ultimately, I sadly don't know how the whole "we need to test everything" story ended, as my internship ended not too long after.
@javier.alvarez764
@javier.alvarez764 Жыл бұрын
Did this in a project of my previous company. The project previously have 0% code coverage. To achieve 85% code coverage I did unit testing for everything.Literally all lines of code in the class, we also call this mutation testing. It made me better at testing. But what matters most is if you do integration test, or test from end to end. From the entry point down to the bottom level. End of the day you just do it and stop complaining. Being able to test them will make you a better programmer at the end of the day. You will learn best practices to avoid bugs and potentional exceptions.
@canthandle1t
@canthandle1t 6 жыл бұрын
Many interesting and valid comments. One thing that hasn’t been mentioned and is a bit quirky is how TDD contributes a bit of gamification in how you write the software. Given the knowledge of how gamification and productivity relate one could conclude that TDD is a productivity tool. So, where’s the gamification element in TDD? A struggle of software development is the delayed feedback of your effort. Sometimes you do a lot without seeing the immediate benefit. With TDD you develop against your unit test trying to get it green. The feedback cycle is more immediate and the task at hand is more targeted. A core element of gamification is that the goal is clear-TDD is basically the definition of the goal.
@alexbuhl1316
@alexbuhl1316 5 жыл бұрын
That only works for about 30-40% of people, I would assume? That behaviour is very personality driven. It also reduces the amount of foresight put in drastically. Not everything has obvious benefits/drawbacks, most are highly dependent on personality(-interactions), which is why the project often fails at HR without anyone knowing.
@meanmole3212
@meanmole3212 2 жыл бұрын
Green dopamine candy bar for your brain.
@owenpalmer8242
@owenpalmer8242 2 жыл бұрын
Good engineers have the foresight and patience to see a project through without needing immediate feedback. They know when they're being productive. If writing a test makes them more productive, so be it. But using TDD to make yourself feel more productive is counterproductive.
@julianandresvargasarboleda3618
@julianandresvargasarboleda3618 Жыл бұрын
what makes me feel happy is to write interesting code and be productive, what makes me feel bad is need to modify 10 unit tests to just modify a simple response object. or needed to refactor bad writen tests for a programmer that was fired 1 year ago. what you said I have never feel happy by seeing a green button in my screen
@globalistgamer6418
@globalistgamer6418 Жыл бұрын
If this even works, it could be counter-productive because there would create a conflict of interest when the same person is designing and writing both the tests and the software, potentially encouraging them to create excessively superfluous tests and optimizing testability over other elements. I hope this wouldn't happen, but it might explain some of the excesses people in other comments have reported witnessing...
@haruruben
@haruruben 5 жыл бұрын
I think there's a ratio of test code to app code where the testing becomes a net gain on productivity because you don't have to go back and manually retest things and you can quickly see if your new stuff has had unexpected ramifications
@wj11jam78
@wj11jam78 Жыл бұрын
I think, like most things in programming, TDD is appropriate for some things and not for others. If you're making a video game, TDD is probably overkill. If you're writing software for a manned space mission, making absolutely certain that everything works 100% correctly is probably a good idea.
@johnwalkerlee
@johnwalkerlee 6 жыл бұрын
When project managers aim for 100% coverage "I found a metric for my spreadsheet!"
@johnjackson9767
@johnjackson9767 4 жыл бұрын
Exactly.
@myungkeon
@myungkeon 4 жыл бұрын
@@johnjackson9767 hey John. I've been a subscriber for a while and I absolutely love your content from the engine videos to programming videos. This is definitely the kind of video I'd expect to see you in the comments of 😅
@stangeorge6893
@stangeorge6893 4 жыл бұрын
If you listen closely you can hear Uncle Bob screaming.
@etodemerzel2627
@etodemerzel2627 3 жыл бұрын
Good.
@KANJICODER
@KANJICODER 2 жыл бұрын
I am making a MMO in JavaScript with variables that are exactly 3 or 7 letters and often unpronounceable as English words just to spite Uncle Bob. I am also putting all the code in ONE FILE. Oh, and it's written in C99 style even though it is JavaScript , using data oriented design principles. Because fuck OOP. ( Except for UI. OOP is pretty good for UI )
@HartleySan
@HartleySan 9 ай бұрын
Jonathan's bit at the end about ignoring costs is right on the money (pun intended). I often struggle trying to make that exact point at places I work.
@thomasmolby
@thomasmolby 7 жыл бұрын
I do not think this is completely black and white, however I did work in a large web development team where 100% test coverage and pair programming were mandatory. Writing tests took precedence over exploring the problems we had been tasked, and everything took forever to make. As Jon talks about in the video, people were more focused on the tests than the problems. Once some of my colleagues spent 4 days figuring out how to test that the color of a button was actually the color that it was supposed to be and THEN half an hour to make the button change color. I wish i was joking... Generally, when my colleagues paired up, I often noticed that their back and forth would lead them into making really weird choices. Once two guys talked each other into making elaborate abstraction layers around a library for doing graphs and charts, barely consulting the actual documentation. They were very proud of it too. However the end result was a graph that looked nothing like the design and only read right at certain resolutions... but another two sprint cycles would help get it within acceptable parameters... Enforcing TDD and pair programming made sure people never got to sit down and just figure stuff out. Im pretty sure my colleagues with very little html, css and javascript experience would get a much better chance at actually getting that experience if they had been allowed (and allowed themselves) to sit down and try out some stuff. I'm open to the possibility that tests and pairing up could help a lot in certain cases. If you have a big complicated data transformation, why wouldn't you test out a large portion of inputs and outcomes to ensure that it does what it's supposed to? And why wouldn't you want other people to give their perspective on your work and your process? and the other way around? But not allowing people space and freedom to explore and consider a problem because you found the one true way to do software is just very, very dumb.
@smallbluemachine
@smallbluemachine 5 жыл бұрын
If you’re in a large web project with a “dynamic” typed language, unit testing is the only thing preventing you from taking your own life.
@32gigs96
@32gigs96 5 жыл бұрын
smallbluemachine looool
@fingerofkawaii
@fingerofkawaii 4 жыл бұрын
Based on my experience, you aren't writing unit-tests for the benefit of this sprint. You're writing unit tests for the benefit of the poor sod who will need to implement a change/patch up a bug related to your code down the line. Maybe you'e in the project and your memory is fresh. But maybe a year has passed since you've written that code and it's like a different person has written it. That's where unit tests save your ass. They let you explore how your code works in small chunks to find the bugs. It helps you understand the codebase if you're new to it. It is there so that your functionality would work correctly even after a few years of continuous work on that code. But a 100% code coverage also means you need to write tests for absolute boiler-plate, which makes little sense. Hell, covering units makes little sense unless you actually cover the critical part of your code. You write a test for one outcome of a bool, it counts as 100% code covered, but is only 50% of paths. Have you truly covered everything? The failure of TDD and code coverage metrics is that the developers will game them to do as little as possible, to cover the most code.
@mariobisignani4477
@mariobisignani4477 Жыл бұрын
Amen
@artiumnihamkin9206
@artiumnihamkin9206 4 жыл бұрын
From my personal experience, exploring solutions to a problem or debugging with another person is very productive, more than 2x. I never thought that pair programming means two people should share a keyboard and do the actual programming together.
@Tegyukfel
@Tegyukfel Жыл бұрын
First of all, Atrium: my comment is not addressed to you, but everyone - I just started typing my thoughts about 2x productivity and it got out of hand. I disagree, but don't take this personally, I just want to start a conversation. So, to my point: I think it's a great method to have the 4 eyes principle fulfilled immediately when you have to implement something in a critical part of a complex system. It would take longer time for your peer to understand and review the code. But still, pair programming are only justifiable in circumstances where a critical failure would require immense resources to fix either due to time constraints or sheer complexity. Now, I want to reason about that making pair programming mandatory (which some teams or even companies do) is actually a bad thing. Thing is, (in my opinion) it is hard to stay objective when doing pair programming. Your opinion of your partner will impede your professional abilities. As a driver, you might not make the same choices if you are a more junior or more senior as your navigator. It might be a good thing, preventing you of falling into bad habits, or it could be handicapping you in reaching your full potential or productivity. From a navigator standpoint... If you are sligthly more junior, you just simply might not get the courage to question your driver's capabilities or choices. Or as a senior, you might just want to let your more junior colleague flap their wings, if it works, you might not mention some insignificant mistakes, to implement the thing faster. Why is this? Because ultimately, both of the programmers want to be productive. And the social aspect of pair programming adds a lot of friction. In an ideal world, in all of the questionable programming choices, the driver and navigator will come to a consensus which will be the best solution. How much of these discussions will be about potential bugs averted? How much of these will be about cosmetic and syntactic choices? Pair programming ultimately adds a layer of social friction. So not only you are paying 2 programmers for 1 programmers job, you add an overhead as well. An engineering manager or someone has to decide: what is the cost of a critical bug in this system? If we reduce the number of critical bugs from 5 with 1 programmer to 2 with 2 programmers... Do we really have a net positive? Or that 1 programmer could just fix the issue in 0,2 programmer time for example? Do not get me wrong, I think pair programming is a great technique, I just see a lot of potential obstacles. As I mentioned, different seniority levels could create issues. So ideally you need to have the same seniority level. Also, you would need a really good relationship and cohesion with your partner. Also, think about your mindset as a programmer - what does it take you to get into the flow? In my opinion, if you want do to do more than double the work with two programmers, both of them must be in the flow in the same time, be the same seniority, and have a really good cohesion which you might only get after years of working together. In my experience, the ideal productivity of >2 for 2 programmer working is impossible. You can approach it, but both of you need an exceptional cohesion and understanding of each other. If you find a partner like this, you hit jackpot basically. Just think about it in your individual point of view: let's pretend you are a senior programmer with 10+ years of experience. For pair programming to return the investment, every other of your thoughts would be topped by your driver / navigator's ideas. You have one actionable, perfect thought, and before you could think of another, your partner already thought of another actionable, perfect thought. It's highly unlikely in my opinion. Of course, that's not how the world works. Sometimes you could have an epiphany which makes you realize the ideal solution, have a paradigm shift or just accept defeat and scrap everything. In my opinion you can come to this realization much faster if you share your opinion/code with your (previously described) ideal peer. This is one of the strong suits of pair programming. Kind of like if you had a rubber duck - once you verbalize your ideas, you might realize the flaws or advantages. So I think a team should try to explore pair programming in PoC projects and rapid prototyping. This is where one should ping-pong ideas between each other, and share keyboards often. This is the environment where instant feedback of your peer is a must. In my opinion this is the only context where 1 + 1 engineer could potentially create 2 productivity.
@DaleReidy
@DaleReidy 7 жыл бұрын
I guess my rebuttal is - there's always a trade-off, and experience guides when to do X, and when to do Y. If the acceptance criteria of a piece of new functionality is expressed via a suite of unit tests - that's cool - If there's ever a regression then the test(s) will fail before the broken code makes its way into a live release, saving QA time reproducing the issue, and the Customer/Player's frustration of using a buggy product. If the acceptance criteria changes on a basis that's regular enough that these tests become painful, then there's something fucky going on. Maybe the level of churn on this piece of functionality is so regular such that hard-coding it and covering it with unit tests is a criminally terrible idea - so one option is implement a scripting language... or some other configurable mechanism - and then have a scripted bot/play-through test to verify that the mechanics work in-game, and bin off the unit tests - they were never around long enough to pay for themselves. As for pair programming - I find it absolutely invaluable for spreading knowledge of the code-base being working on - people shouldn't work in isolation. You don't pair program on noddy stuff - that's a complete waste of time - but for the tricky stuff, having somebody to throw ideas around with is great. Investigating tricky bugs, and introducing new team members to the code are two use cases. I've no idea why I wrote this, but it has been cathartic.
@LPFan33
@LPFan33 4 жыл бұрын
Good comment to be honest, I really agree with you. In my experience TDD and PP are very valuable practices, but it definitely depends on the situation and not to mention the quality of the tests. I know people who write very tightly coupled and therefore fragile unit tests, which makes them just terrible and annoying
@LisandroLorea
@LisandroLorea 2 жыл бұрын
In videogames things tend to change a lot all the time, and delays in releasing your game/game update can be more harmful than say, a service like Github or Gmail. At the same time minor bugs in a live release are more tolerable as long as the game is overall playable and fun. A sword doing ten times more damage till the zero day patch is less harmful than a bank transfer being ten times the intended amount. Having tests is perfectly fine if you have parts of your game that are very stable and where you don't want a refactor to break everything or where the costs of a bug in release are much higher. For example you don't want any updates to break the player progress so any changes to things like saving/loading probably need good test coverage. Test Driven Quality Control is not an issue, the problem is thinking that tests can drive software design. That's BS, especially in game design. Writing tests afterwards where you need them is nothing special or new.
@aichpvee
@aichpvee 4 жыл бұрын
Every time someone says “pair programming,” all I can hear is “pear programming.”
@PieceOfDuke
@PieceOfDuke 4 жыл бұрын
Maybe it's peer programming.
@johnjackson9767
@johnjackson9767 4 жыл бұрын
The best kind of programming.
@criptych
@criptych Жыл бұрын
Still better than Apple programming.
@DodaGarcia
@DodaGarcia 6 ай бұрын
Last time I bought a pear it was definitely poorly programmed it because I found a bug in it.
@eugenkeller
@eugenkeller 6 ай бұрын
Is it a sex thing?
@wforbes87
@wforbes87 2 жыл бұрын
"if you're doing anything interesting" *laughs in business application*
@unchartouille1208
@unchartouille1208 5 жыл бұрын
Writing unit tests is helpful for other developpers that will see your code to understand the logic behind. Writing unit tests is also very helpful for yourself because it simply trains you to be more vigilant. The only moment I think unit test is really counter-productive is when you want to explore empirical ideas, during conception or prototyping.
@IstvanTM
@IstvanTM 11 ай бұрын
When I was a junior engineer learning TDD and doing pair programming helped me a lot to improve. Now I dont do tdd anymore but it was a good learning experience
@doxanthropos
@doxanthropos 4 жыл бұрын
Hm, while I like the reasoning about most of the points, there are at least two major assumptions that make me sceptical about all of them, because they are in one point just false and in the other point a strawman. Pair Programming: The assumption that no one has done the math on the effectiveness of programming is just not true. If you do a duckduckgo/google/ecosia/whatever search, you will find a lot of academical studies about exactly this question. So the main assumption (no one has done the math) is wrong. But even more: while I only skimmed the results to see if there are studies at all, the ones I looked closer at, seem to show that the productivity of a pair is most of the time not smaller, but bigger than the one of two individual devs, with better code quality on top. (Not claiming it is so, but a first glance at the literature suggests it). TDD: The argument seems to be going against "writing all of the tests before you even start to write program code" and that is just not what TDD is. If you read any book about TDD or watch some big TDD proponent like Bob Martin explain it, you will see that it is to be very incremental, like write one test, write some code to make that pass, see if it passes, without breaking the tests that came before, repeat. I do not claim that this is necessarily better as other ways of programming, but it is not what is presented here as "you can't write your tests beforehand, because you do not know what you are building".
@douglasbushong3920
@douglasbushong3920 Жыл бұрын
A large part of it is the tension between efficiency, speed and reliability, and the level of consequence for error. If reliability is prioritized over efficiency, then the extra testing makes sense. If the consequence for error is high (i.e., life and death), then the extra cost of testing makes sense. This is rarely the case for game development.
@Daniel_Zhu_a6f
@Daniel_Zhu_a6f Жыл бұрын
In some situations (i've mostly encountered it with math & algorithm problems) the call signatures and tests are a no-brainer, and you can reliably write them before the meat of the program (and it makes perfect sense in that context). Could it be that TDD is a practice from college "algorithms and data structures" course that someone extrapolated to a whole field of programming?
@Plrang
@Plrang 6 жыл бұрын
Well, certainly people don't generate bugs while writing tests, only while writing the regular code ;)
@alefratat4018
@alefratat4018 4 жыл бұрын
Yes, unless you write tests for testing the tests :D
@4.0.4
@4.0.4 4 жыл бұрын
That's actually the point of writing the test first, so you see the test (properly) fail, write the code and see it pass. If you write the test after the code, there's a non-trivial chance the test passes regardless because you wrote something wrong.
@peripheralarbor
@peripheralarbor 3 жыл бұрын
Who tests the testmen?
@leander11
@leander11 4 жыл бұрын
On 3:10 Jon Blow uses a word "Celus", "Sellus" or something, english isn't my first language, what is that word?
@sasuke2910
@sasuke2910 4 жыл бұрын
It's "Zealous".
@leander11
@leander11 4 жыл бұрын
@@sasuke2910 Thank you! Wow I've never heard that word, I will use it in my English lesson and see if my teacher knows it.
@peterfarr9591
@peterfarr9591 6 жыл бұрын
As much as I dislike pair programming there actually is a lot of evidence around the fact that in most cases two programmers working together will have higher code output in terms of both quantity and quality. I think the bias there is that most people tend to be extroverts rather than introverts an I think those studies led to the idea that everyone should pair program when doing so is counterproductive for more introverted developers. My two cents anyways
@andrewhaust3382
@andrewhaust3382 2 жыл бұрын
I love pair programming and have seen great benefits with it. We used to rotate pairs daily and generally stuck to a "rule" that no person could stay on a story for more than two days. That meant that if a story took three days, then the two people who started it weren't the same two who finished it. Obviously I understand that this isn't for everyone and you have to have a mature team but the result was that for the most part, every part of the system had at least three people who had some intimate knowledge of it.
@ishashka
@ishashka 2 жыл бұрын
To me, the main purpose of unit tests isn't testing for bugs, but "locking" a unit in place - ensuring that even if you make some internal change, the external interface of the unit works the same. Basically, they're to make sure you don't break in the future what's already working.
@awesomedavid2012
@awesomedavid2012 Жыл бұрын
That sounds alright but you have to be sure that your unit will never change in the first place. And it takes a long time to be that confident
@blacklistnr1
@blacklistnr1 Жыл бұрын
As someone who's had a really nice experience with pair programming: it works and it's amazing, but you need good synergy and separation of concerns.
@OMGclueless
@OMGclueless 4 жыл бұрын
IMO there is value in unit testing if what you mean by unit is "an observable piece of behavior that your customers and/or other teams within your org expect to continue functioning."
@dinhof
@dinhof 6 жыл бұрын
I believe pairing is valid, when you're stuck and/or new to the tech being used. Agree on productivity loss though. Making pairing a cultural thing, that is, mandatory in some way is awful.
@anonymous4711_
@anonymous4711_ 4 жыл бұрын
On the lowest level, a company hat does pair programming has the organizational ability to take a measure that is not 100% brainded beancounter efficient and commits to the goal of being be better. This in itself is already amazing. If you are a very good programmer who goes to the place where it hurts, by actually thinking through what the code they have written does, including all the edge cases, instead of doing an approximation and pressing F5, you won't need that. But that is rare. You have the very same temptation whenever you write code. Do you really grok your own code with a clear mental image of what is going on, what edge cases apply etc., or do you have a heuristic where you are "close enough", let the code run until it shows you where it breaks down, and then code a little more...?
@buflen
@buflen Жыл бұрын
that's crazy to me that Jon was working on sokoban 6 years ago.
@4.0.4
@4.0.4 4 жыл бұрын
I wonder how many programmers have the windows calculator set to "programmer" mode. I even forget it's there when I could actually use its features.
@mettaursp309
@mettaursp309 4 жыл бұрын
I sometimes use it if I'm working with binary data, but I always find myself switching back to standard mode whenever I'm not doing something that is bit fiddling related. The lack of support for floats is horribly restrictive.
@bonsairobo
@bonsairobo 9 ай бұрын
My rules of thumb for testing: 0. Spec out the feature, decompose it into sub-problems with solutions using some data structures and algos. 1. Write a stub API in the layer where it needs to be integrated. This is how you discover the API shape. 2. Write a few realistic test cases for the API. Does not need to be exhaustive. Its just a way to set more goals for your implementation than just the happy path. 3. Implement the API. 4. If you have to write a tricky algorithm or data structure, TDD it. It's a judgement call how much benefit you expect to get out of the tests. That's why you don't unit test trivial stuff.
@mvargasmoran
@mvargasmoran 4 жыл бұрын
The thing about Pair Programming in my case is that I hammer-in code standard and practices, understanding of the framework, most of the time fill-in some holes in the knowledge and stop, not refactors, but costly rewrites that most of the time demoralize the Juniors. To accomplish that I've sacrifice probably the whole afternoon (when I'm already tired of coding) to bring junior's up to speed, of course they halve or completely take away my productivity for the day, but good Juniors repay you with work, the ones that are looking for someone to do their job I push for them to be fired.
@wikkidize
@wikkidize 4 жыл бұрын
classic psycho dev, good job moron
@NukeCloudstalker
@NukeCloudstalker 4 жыл бұрын
@@wikkidize his approach is entirely rational and perfectly moral. He expects people working to add value - and for this he doesn't even mind sacrificing some of the value he himself brings, as the new dev becomes a proxy through which he can add value himself. It's reasonable. Devs that aren't doing their job need to be fired, this is one of the biggest issue in the industry that i've seen - devs that can't do their work don't get fired often enough, which leads to high maintenance costs. It would be absurd in any other occupation, but for some reason people seem to accept it in software dev. Not to mention that often the boss can't even tell what they should be expecting of programmers.
@glowiever
@glowiever 4 жыл бұрын
@@wikkidize natural selection, asshat
@yurtle1851
@yurtle1851 Жыл бұрын
Pair programming is fantastic for many reasons. if you're working on many easy tasks, sure, its more efficient to work in parallel and not communicate. if you're working on one really hard problem, its can be very helpful to work through the problem with someone else, or even a group. Also, even if you aren't working on a really rough problem, its useful to see how other people program. Whenever I pair, I almost always both learn something new and show someone else something they didn't know. And of course if you have a junior engineer pairing with a senior engineer, the junior engineer is going to learn a lot. Sure, the senior could have gotten other work done during the time they spent pairing, but I think the team as a whole benefits more from the knowledge transfer.
@space_cowboy007
@space_cowboy007 11 ай бұрын
extreme programming stated that you had to pair all the time
@Gabzes
@Gabzes 5 жыл бұрын
TDD is something that is well suited to developing things like rest APIs and shit, not games
@cas1652
@cas1652 5 жыл бұрын
when Jon was implementing cpu intrinsics he was basically doing TDD except that he checked that the output matched manually. Whatever floats your boat, I guess, but a minimal test framework with some asserts and legible output would've gone a long way und would guard the correctness of his implementation nearly for free.
@sasuke2910
@sasuke2910 5 жыл бұрын
I think you're right, and I think Jon would agree. If the results you're looking for are easily mathematically verifiable, then TDD makes more sense, like adding SIMD or implementing an SQL database. The objection is for using it for more deeply interconnected systems like general gameplay. That's why he says TDD programmers aren't working on anything particularly "complicated" or "interesting".
@TheOtherClips
@TheOtherClips 4 жыл бұрын
@@sasuke2910 Using it for larger systems would be integration tests. Part of the point of TDD is to help you structure your code as a group of 'units' that take inputs and produce an expected output. Now I agree that can be difficult, especially when your code is heavily dependent on a game engine (like Unity). Tests also serve as a contract or reminder for the future that particular behavior was intended and not a bug. The problem is that JB has worked in one industry and he makes declarations regarding projects the scope of which he has never even imagined. Now, I agree that TDD is bad, but he seems to poop all over unit testing in a way that is typical of him, but fairly short sighted
@MrAbrazildo
@MrAbrazildo Жыл бұрын
0:34, yeah, I use to develop a f() in a kind of uncertainty about how it'll be it's final signature. That's also why I appreciate so much the auto returning type. 1:05, I guess game is a too wild subject. In other areas, people seem to approve TDD. 2:08, this was a key observation. There are many projects, like scientific and databases, in which all the complexity stays inside f()s. But the actual danger become between f()s. Games are prone to have this kind of issue. And that's why I defend classes to hide variables, that may cause a disaster on this field.
@behnamrasooli8801
@behnamrasooli8801 7 жыл бұрын
One benefit of TDD is to help you to understand the system you're trying to design/implement better by breaking it down to smaller pieces. But if you already know what you wanna implement, then yes, you don't need to be so obsessed about TDD.
@DerSmoli
@DerSmoli 7 жыл бұрын
This! As with everything: Don't make a dogma of things. Sometimes it's amazing to write tests beforehand. Sometimes you write them after to stay relaxed, because you're developing on a constantly evolving system. Choose the right tool at the time.
@LunaticEdit
@LunaticEdit 4 жыл бұрын
0:38 Honestly, this is exactly why TDD is a thing.
@edwarddejong8025
@edwarddejong8025 5 жыл бұрын
great talk. Mr. Blow is a very experienced programmer, and no question in my mind that TDD's net effect is to increase billable hours.
@skepticmoderate5790
@skepticmoderate5790 4 жыл бұрын
You say that like it's a bad thing.
@ReasonMakes
@ReasonMakes 4 жыл бұрын
@@skepticmoderate5790 It is a bad thing. If you just want to work for the sake of working you can hand wash clothing all day like we did before we had washing machines (or like some people in poverty still do). Trying to "create" jobs like that is insanity and is anti-progress. We can and should continue to automate systems that are this repetitive and disinteresting. That way we can spend our time doing more meaningful things.
@MorningNapalm
@MorningNapalm 2 жыл бұрын
You don't have an own opinion? Why does anyone need Jonathan Blow to tell them what to do? Try things out!
@friendlyfripptit2228
@friendlyfripptit2228 2 жыл бұрын
interesting! I'm working at a bank and we do mob-programming. How I think about it is that it's not about the programming at all, it's about the process. Instead of doing stuff through jira with PRs and stuff, everything just goes into the main branch. And new people hits the ground running. So it's a process thing, not a programming thing. Maybe Herr Blow would classify that as "uninteresting work," idk.
@goldsucc6068
@goldsucc6068 Ай бұрын
but unit test in classical testing is not neccessary small amount of code. it should be fast, isolated manner (to run in parallel) and test unit of behaviour. you can test very big interconnected chunks of code as a unit of behaviour
Жыл бұрын
In big companies we write unit tests, integration tests and verification tests. So we write tests on multiple levels. Because sw base is huge and it needs to be tested in many levels. So unit testing is just one level
@DestroManiak
@DestroManiak 2 жыл бұрын
0:38 "you dont know exactly what you are building yet, if you are building anything interesting" they are not building anything interesting
@MaxAmadeusW
@MaxAmadeusW 7 жыл бұрын
It may be difficult to employ unit tests to many parts of game development due to the nature of it. However there are certain tasks that are still very fit to this, versioning problems for instance, e.g. making sure the game state doesn't break backwards compatibility, especially useful if there are many people implementing code without supervision. Regarding pair programming, I think the statement made implies effeciency is all about the code *you* write, which is not necessarily true in larger teams. Not everyone is a rockstar or exceptionally good programmer either, which makes it more important to have an understanding of how others work and how they can improve. Pair programming might slowly eradicate those bad habits of certain individuals in the long term. I think there's a lot of hype regarding programming practises though, I've seen all from extreme code coverage requirements to dashboards measuring "code smell" and whatnot. Those teams however has had focuses way off just making things work, adding actual features, etc. This is also why being indie is super cool, since you get to decide and have the last word regarding all of this. In no way do I believe that productivity scales even near linearly with the number of people working on a project. Some of the greatest software/games in the world often starts with just one person, or even finishes with one.
@sdporres
@sdporres 6 жыл бұрын
I used to share this opinion, but have recently changed my mind. Here are my observations: 1) Unit tests help you to define (and verify) your assumptions about what the code needs to do 2) In gamedev, things change often - not because they are buggy, but because of iteration over game mechanics and features 3) The more code you carry with you, the more you have to rewrite - this includes tests 4) Real time game loops are a pain in the ass to debug From these 4 points, I think unit testing has real benefits and advantages for gamedev. However, gamedev code is inherently "different" than "enterprise" code, so i think testing needs to also be different. Ultimately, how well and easy it is to expand and maintain your test suite is going to rest on the architecture of your code. (I imagine many projects die under their own weight) In my case, I have found peace of mind and time savings in writing tests for my inventory management library (putting things in and taking things out of containers while observing complicated rules), AI (complex decisions in real time that are difficult to step through, and often require lots and lots of logging to understand), and integration. Another caveat is that my unit tests are significantly different than "normal" tests because of the need to setup and run the game loop. Without unit tests, your alternative is to run your game a lot - ive done that for years, because of my closed minded thinking about unit testing. I have now swung the other way. One last word: unit testing and asserts are a much better way of finding problems that exceptions and logging. Ultimately, you will need a mixture of it all.
@RoyBrush
@RoyBrush 6 жыл бұрын
I disagree with Johnathan Blow a little bit, I think, because unit tests are extremely useful when you need to refactor code and change it, so I do think there is a use for them, but I think he's right about TDD having a massive productivity cost up front. In a game which has a almost defined development period, you write it, and you know the requirements will never change again once it has launched (for most games anyways), unit tests might never be required. But even in other application types, TDD still might not be a good answer. I've often just written unit tests at the point where I *needed* to refactor a piece of code. Since the primary benefit of unit tests is regression testing in my experience, this is the best compromise in terms of developer productivity that I have found.
@jpratt8676
@jpratt8676 4 жыл бұрын
Right, you want TDD at the boundaries of an API that you want to be stable. You don't want it on implementation details with made up data and any less than well understood functionality.
@aoeu256
@aoeu256 Жыл бұрын
The renamed it from TDD to BDD, because the tests should be testing business requirements and the behavior of the program you want for hairy code. If you write yoru tests before your code the example tests can also be fed to chatGPT to help it generate code.
@DieterPrivate
@DieterPrivate 4 жыл бұрын
The problem is that a lot of developers can't write great unit tests which documents the wanted functionality (black box).
@nickwilson3499
@nickwilson3499 2 жыл бұрын
How is a black box in any way good?
@Kradiancy
@Kradiancy 2 жыл бұрын
@@nickwilson3499 Because you can change what's inside without changing the tests. That's something that Blow skims over in his analysis I think - good unit tests don't need to be rewritten constantly because they test the behaviour of public APIs which are subject to minimal change.
@bruterasta
@bruterasta 6 жыл бұрын
TDD is hopeless. However when creating library I don't know more efficient way to defend yourself against regressions than writing automated tests. Constant and repetitive manual testing waste more of your time.
@joaoedu1917
@joaoedu1917 4 жыл бұрын
A traditional library is the best case for unit testing ever (not sure about TDD), because it’s usually pure functions, or something completely stateless, a single bug could ruin several projects (of course there should be a release process as well) and so forth.
@swapode
@swapode 4 жыл бұрын
I think a good approach is something like this: You write code normally and while you do that certain parts will reveal themselves as generalizable, so you move them into a library of sorts. That's when you introduce tests - but not necessarily in the naive code coverage way (I have a function, so I write a test for it) but by writing expected use cases with assertions. This doesn't just serve as a regression protection for your API but is also serves as reliable documentation. I particularly like what Rust does in this regard: You write doc comments like you normally might - but any code examples in there are automatically run at compile time. So you're testing your API both for regressions and for its documentation to be correct.
@picosdrivethru
@picosdrivethru 3 жыл бұрын
I like having tests on my functions, I'm a noob, but when I make sweeping design changes, to my tiny ass scripts lol, I dont know, its nice to see what fails and fix it pretty fast, so my 3000 line program is like another 3k longer with various basic tests to check outputs... I don't know.. it seems useful...
@redhawk3385
@redhawk3385 Жыл бұрын
I always didn't understand because TDD because it didn't make sense to write test first, then code, then something?
@KANJICODER
@KANJICODER 2 жыл бұрын
"Write the tests first" is for business programmers who are given the API they need to fulfill up-front. I think you should write whatever you have the "clearest idea of" first. Sometimes that can be the tests. But at best "write the tests first" is a "dominant strategy". AKA: A strategy used by someone who doesn't understand the game well enough to have their own personal strategy that beats the dominant strategy. I suck at poker, so I would defer to whatever the dominant strategy for poker is.
@unduloid
@unduloid Жыл бұрын
Unit tests are not primarily for testing your code. They are primarily for developing. They're a way to get shorter feedback on whether your code works or not, because you don't have to compile everything into a working application before you can see if it actually works or not.
@PROdotes
@PROdotes 10 күн бұрын
I think it would depend a lot on what you're doing... when you're making a game, you can't always unit test just 1 small thing, cause usually the interactions are important... But say you're a company making software for a big bank... then you want to unit test everything, cause the same input will always have to give you the same output... and every little piece handles a specific task...
@smestre
@smestre 6 жыл бұрын
I don't know about TDD but pair programming really helps me stay focused and productive for longer periods of time than i'd able to when writing code alone
@tonyrigatoni766
@tonyrigatoni766 6 жыл бұрын
I have no professional experience with TDD or Unit Testing (was really only exposed to it in school), so I really have nothing of substance to say about those topics. However, I fully agree with Jon about Pair Programming. Every time I've ever tried pair programming it's slowed both me and my partner down. In every case it would have just been faster if we had just worked on separate aspects of the software at the same time and just linked it together when we needed to. It's a massive productivity suck in my experience, and it's really pushed on young programmers these days as though it's some kind of "best practice". When I was in school for compsci just 7 years ago I got shown the same video about pair programming in three different classes, and I never had good results with it.
@roxferesr
@roxferesr 4 жыл бұрын
I think pair programming has to be put in context. If you put two experienced programmers to do something trivial, then yes, it's a huge waste of time. If you put the same programmers to do something complex, bouncing ideas can result in better code (you are trading speed for quality). If you pair an experienced programmer with someone with less experience, the team productivity improves in the long term as the inexperienced developer get better (trading short term productivity with team building and long term productivity)
@shavais33
@shavais33 4 жыл бұрын
Over the years, several times, I've attempted to re-approach unit testing and test driven development in the hope of finding a faster way to get things done. I mean, if you have this suite of tests, then theoretically when you go to change something, you can run that suite of tests and if they're all green, awesome, you haven't broken anything that was working before. Very helpful, right? And, it seems like tests should be able to kind of help me write my code more quickly by giving me a way to quickly test what I'm working on kind of more-or-less in isolation. So recently I've considered reapproaching it again in the following general way - I define some data, I define an api of operations on that data, I put in some stubs for the api, and I write one test for one of those stubs. The idea is that the test actually helps me write my code, because it makes it possible for me to just right click a unit test on the unit test list and select "run" and see whether or not something I'm working on is going to work, more-or-less in isolation of anything else. It's quick and I get debugging feedback in my little output window. My code stays right there in front me while all that is going on. No window switching, etc. I'm just taking advantage of xUnit's or msTest's ability to do that. And then I can build up the tests while I'm building up the functions I'm working on (and the functions they call and so on). And, when I go to consume the functions in higher level functions, I have my test code to refer to - maybe even to copy/paste/modify. But in writing games, this where I get stuck - in a game, in general, for the most part, the thing I want to test out is something visible or audible. I need to see the sprite show up on the screen. I need to see the shot fire when I press the fire button. I need to hear the explosion sound when it blows up. I need to see whether or not there are any janks or jitters when I start adding more and more sprites into the mix. i feel like the reality is, for games, you really need a Human to test them. Most of what you care about testing has to do with look and feel and sound. So there's no way for the machine to flip that test green on it's own? I mean maybe there is, but I'm sure not going to spend my whole life trying to get a machine to be able to tell whether or not some interactive visual and auditory and maybe even tactile simulation looks, sounds and feels right? And as far as helping me quickly test something in isolation goes - stuff in games just doesn't come in isolation. Anything and everything requires a whole bunch of other things to be there for there to be any shot to fire or anything to shoot at, et etc. etc. I'm just not going to spend millenia setting up some kind of fake testing environment when what I have of the engine so far, and/or of the game so far, makes for a perfectly good testing environment as far as human testing goes, especially if I've already decided I'm not going to try to get the machine automagically testing things for me. I mean, not that I don't put in player/tester triggerable tests that spawn stuff other than what the game normally would in order to test the engine's limits and the boundaries of things and so on, I do, but that's not really a "unit test," it's more a "test function" of the game that facilitates human testing. So I agree with JB, I don't think TDD really makes sense for game dev. For corporate software, maybe, but not for games.
@astrixx
@astrixx 2 жыл бұрын
As a developer that does web stuff and data munging by day, I agree. Code that manipulates pure data ESPECIALLY lends itself to unit tests because you want to those computations and filtering always consistent. During my free time I code games and it's like exactly the opposite. Nothing I make stays still for very long. I'm ALWAYS creating, experimenting, ripping out code and adding new stuff. Apart from the fact that a lot of the testing is experiential/performance-oriented in nature, the code velocity is very high. The cost/benefit for unit tests here is pretty frickin' small.
@onepointtwo500
@onepointtwo500 2 жыл бұрын
You can use Behaviour Driven Development (BDD). For instance, you could know you want your player to jump, shoot a rocket over a wall, have the rocket follow a certain path and then explode and produce a non-distorted audio clip at the right time. If you log as much data as possible and compute and RMS error from the desired path, then you have assessed the behaviour of your game without the need for human testing.
@bertiesmith3021
@bertiesmith3021 8 ай бұрын
I choose to define unit tests as any test which does not require external input or output, and no external dependencies. So they run very fast, and very reliably. Whether you are testing the lowest level or highest level functions is a separate argument. Personally I test both when ever I can, and test to the stated definition of the unit being tested. If this ends up with less than 100% coverage (outside of a few edge cases which are essentially impossible to reproduce if your program is functions ing correctly) then this implies that the implementation has coded for situations that it doesn’t need to, and so refactoring the unit is the appropriate response (usually).
@jonmoore176
@jonmoore176 16 күн бұрын
TDD is pretty misunderstood and is often done badly. Done well it works, particularly server side, business apps etc, it is a tool for designing your code. I have no idea if it works in games or not though.
@kaesknacker2738
@kaesknacker2738 Жыл бұрын
The more math-like a function is, the more unit tests I write.
@vectorhacker-r2
@vectorhacker-r2 2 жыл бұрын
Unit testing isn’t the only types of tests you should be writing. The test pyramid is important, unit tests, while import are the base and are complimentary to things like integration tests, component tests, and end-to-end tests.
@broken_abi6973
@broken_abi6973 7 жыл бұрын
I suppose that games, once released, go through very few code changes, and very few features are added to their engine (correct me if I am wrong). TDD would have limited benefits in such model.
@etodemerzel2627
@etodemerzel2627 3 жыл бұрын
Depends on the game. Single-player games are less likely to change in the future. Such as Jonathan's Braid game. But recently Braid: Anniversary Edition was announced. And it looks like at least a partial rewrite of the game.
@gJonii
@gJonii 2 жыл бұрын
This makes it sound like he believes that most of the work software developers do is typing characters, and anything reducing your capacity to push characters onto computer is directly away from your productivity.
@abclef
@abclef 6 жыл бұрын
I've developed a few different game architectures in past years and it's safe to say, it's a good idea to write essential test codes. Why? Because when you work for a team, you never know WHO is going to touch your code, it could be your old partner or just a new intern. So if you have a test runner, it can tell those people, hey man, you've broken something, fix it before commit. As Blow said, tests are slowing down the development, true. So as you can see, there's a tricky point, either you spend precious time to write test codes for everything or clean somebody's xxx in the future, you have to balance. Please expect that, when you're in a company, there's no magic that you can lower the cost dramatically while having a better productivity. Since writing tests are time-consuming, I suggest people do it for those fundamental/low-level parts, say networking and other base frameworks, you definitely want them robust enough. For detailed implementation, as Blow said if someone always writes weak codes, that's his/her problem ;)
@Olodus
@Olodus 5 жыл бұрын
Property testing is for me the evolved, more helpful version of TDD. That actually helps you debug a bug that is found by smartly searching what actually was the feature of the input that the system failed on. But I do agree with Jon that stupid testing and testing for the sake of testing is wrong. Pair programming is something I kinda like. I would never argue that it increases code output by the 2x in all situations but when still in the stage where the problem isn't fully hammered out it feels good to me in some ways to directly be able to discuss it. Discussing it is a large part of how I think when solving a problem. But as I said I would not say it increases productivity by 2x and I know from experience that later in a project it is usually just better for me to go away alone and hammer out the code necessary. Furthermore, I would still say I am an very inexperienced dev compared to Jon so maybe the parts at the start where I feel pair programming offers me something will disappear as I get more experience.
@haruruben
@haruruben 5 жыл бұрын
pair programming is long term benefit, because the person not on the keyboard is discussing and watching and learning. By switching back and forth you pick up the best habits and solidify on style etc. It can help more junior people to learn new ideas and understand with more depth - what's even less productive is trainings sessions and endless code review
@sasuke2910
@sasuke2910 5 жыл бұрын
You're probably right, but this isn't really about novice programmers. And even so, you're slowing down a good programmer exchange for teaching a junior, it's not an easy trade off, there are other ways for juniors to improve without weighing down others.
@haruruben
@haruruben 5 жыл бұрын
@@sasuke2910 even for the advanced programmer, this is a good test for their code so it doesn't become a black box. They need to be able to write code in such a way that other people will be able to maintain and extend it. So, over the lifecycle of a product if more people can understand and make use of the code then you are saving a lot. If you are a startup and you might get shuttered next month, then you probably won't even have junior programmers on your team. But in almost every other scenario where you have a years long project it will be a net gain
@Imbure777
@Imbure777 Жыл бұрын
Pair programming is great in terms of tutoring between two developers where they aren't too far away
@DF-ss5ep
@DF-ss5ep 2 жыл бұрын
Unfathomably based. And he even got the root cause right. And the corollary, in my opinion, is that one day there will be a backlash and no one will write any more unit tests, which also isn't the right attitude, even though it's better than too many tests - just like one day people decided that 0 comments was the way to go.
@yp5387
@yp5387 Жыл бұрын
I am know I am late at the party, but I think unit tests are required when you are working with large teams and not all developers are good devs. so you need to protect your work through unit tests, so you make sure what you have implemented stays there and no one else breaking it. And if they break and also updates the unit test then there is an issue with that dev.
@hey_james
@hey_james Жыл бұрын
There are so many programmers that drank the TDD cool aid and will defend their decision fiercely, regardless if it was write or wrong for them, but because they invested so much time into it. Can't turn back now right.
@henrymaddocks984
@henrymaddocks984 Жыл бұрын
It’s telling how he said “in my opinion” and not “in my experience”
@rpopov71
@rpopov71 2 жыл бұрын
In the early 90s, a professor of mine promoted pair programming practice (not the fad) just because he used it when the machines were slow (he also mentioned perfocards). Then the write-compile-test cycles used to take hours, if not days, at a high price. Then yes, the paired programmers just compiled and run the code in mind. And the cost of their time was less than the CPU time. Then that practice made sense, replacing the days of waiting with hours. Now the computers do it cheap in seconds or less. Now the pair programming slows down the development. The argument that it improves the overall design is just a myth - the design is not fighting with the programming language's syntax while typing. Now the call "do pair programming as it is faster (than what?) and the code is of higher quality (than what?)" is out of any context - this is metaphysics and postmodernism. Now its proponents push another meaning in pair programming - sharing knowledge. Yes, when a senior sits with a junior explaining what to do, why to do it this, but not another way, letting the junior try and helping to debug, mentoring, putting the code in the context of the whole, then yes - this is valuable. I applied it successfully to onboard and grew up developers and seniors. But adding two juniors/newcomers in a pair - what could they teach each other about the domain, the application, the practices, the conventions they do not but have to fit in? The same as adding zeroes.
@llothar68
@llothar68 2 жыл бұрын
I can't take people serious who talk about unit testing and refactoring but not heavily use assert to enforce constant in real life testing of conditions. Add frequent invariant checks of the whole program state to that, at least every frame once in debugging and alpha and partly in beta mode.
@publicalias8172
@publicalias8172 Жыл бұрын
Say what you want about Blow in 2024.. the dude rocked the fuck outta that floral
@mannydamus
@mannydamus 4 жыл бұрын
Reason 2:08
@ddanielsandberg
@ddanielsandberg 5 жыл бұрын
TDD is not unit-testing. TDD is not about testing. TDD is about design. QA is not a department. QA is not a team. QA is not a role. QA is not a phase. QA is the prevention of faults by inspecting & testing the *process* . QA is a systematic way to evaluate quality of process used to produce a product and about how to prevent bugs from occurring in a product being developed in the first place. You *assure* quality by paying attention, taking responsibility and doing it "right", not by throwing it over the wall to be tested. In fact, bugs found in testing should be feedback that your development processes needs to improve. Or as Deming put it: "Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by *building quality into the product in the first place* ." Manual testing, exploration and inspection are important. Just don't think that "testing" is "QA".
@larryd9577
@larryd9577 2 жыл бұрын
If you don't know which tests to write, then you don't know what your function should do. And the function should be able to test isolated, then you are not dependent on an API.
@ddushkin
@ddushkin 5 жыл бұрын
Tests are critical in multi developer teams. This guy develops staff alone AFAIK.
@sasuke2910
@sasuke2910 5 жыл бұрын
Untrue, Thekla currently has somewhere between 10 and 20 programmers.
@ddushkin
@ddushkin 5 жыл бұрын
Jeru Sanders he was a lone wolf for long time. Is this talk from those times may be?
@sasuke2910
@sasuke2910 5 жыл бұрын
​@@ddushkin He was mostly solo for Braid, but did contract work before that, and started The Witness with ~3 other programmers I think. Not sure if you watched the whole vid, but he's not saying tests in general are bad, but "unit test" specifically take too much time and don't catch the important bugs.
@ddushkin
@ddushkin 5 жыл бұрын
Jeru Sanders yeah, I got this part about unit tests. There are scientific researches about introduction unit tests in projects and I have my personal experience for like 2 years, and I just cannot agree with such position 🤷‍♂️
@sasuke2910
@sasuke2910 5 жыл бұрын
​@@ddushkin I'd love to see the research, some of the biggest claims in this video is that no one does research on this stuff. Also, 2 years experience programming? Or 2 years with unit tests?
@rhone733
@rhone733 Жыл бұрын
Been doing software for 20+ years and I've never seen the point of unit tests.
@davidstover6074
@davidstover6074 2 жыл бұрын
It's always refreshing to here arguments against TDD and pair programming. Jonathan is right in that the people who advocate for TDD and pair programming never talk about the draw backs. When tests are written alongside development, they are created with the same knowledge and assumptions. When bugs happen they happen because of the cases you didn't know about or plan for, so your tests are also not going to have tested those scenarios. Also, ironically, tests are said to be useful for refactoring so you know if the refactor was successful. The problem is that major refactoring may completely change the code so the tests don't even compile, so you often can't apply existing tests to new code. So either you have to completely write a new test suite, or refactor the tests, which can add huge costs to the effort.
@zHqqrdz
@zHqqrdz Жыл бұрын
Erm so I'm probably on the other side of the river compared to Jonathan, as I use TDD daily in my job. First I'd like to say I agree that testing **everything** like it's an obsession is a waste of time. I only test when a feature is complex enough or is a very valuable asset for the company (for example, payment). As for the drawbacks on refactoring : this is only true if one isn't knowledgeable enough on how to write tests. The idea is to find abstractions, so that the logic is good no matter what. Then if the implementation is not enough, and code has to change, then one could easily use composition / decorating and the only thing that'll have to change is the initial creator of the unit under test, which will create the unit in the new way you made. Existing and passing tests do not need to change, unless there's an actual bug in the original logic. If the test suite was written by a junior dev, it'll do more harm than good for sure. If it's well written though, it'll result in a very nice to use code base. To be more concrete, think of it as creating a set of LEGOs. You build pieces after pieces, and at some point you put the pieces together (in a controller, for example). PO comes in and says a feature has to change, one of the piece needs to be red and also blue. Instead of painting the red piece with some blue, you add a blue piece to it (you decorate it). The red piece is still red, but now it's also blue, and we can add some blue to any piece.
@criptych
@criptych Жыл бұрын
I know it's a bit cliché, but unit testing is a tool. Sometimes it's the right tool, like when you have a detailed design document and/or strict - often safety-related - requirements; THERAC-25 could have used better unit testing. In game development they're probably overkill; in game _engine_ development it might be warranted. Definitely agree that "'write the tests first' is complete nonsense" unless you actually do have a detailed design document. And (manually) running tests "after every build" is asinine, for less money and developer time you could stand up a dedicated CI to automate builds, tests, and even releases.
@bike4aday
@bike4aday 6 жыл бұрын
“How much code do you want to freakin write?” I don’t know... how much time do you want to spend manually testing everything when you’re refactoring? “Writing the tests before the code is nonsense because you don’t know what you’re building yet.” You need to know the same amount to write the test as you do when you’re writing the implementation. I know what my current state is and I know what I want my changed state to be. I write a test to set the current state and check the changes state after *this thing* happens. Then I write the implementation of *this thing* and the test passes. Amount of code does not equal amount of time spent on writing code. It’ll take me 10 seconds to write a unit test and 10 minutes to write the implementation. And I save 10+ minutes on manually testing that implementation over and over to see if it’s correct. Also, JavaScript is not a terrible language and that’s why it needs tests. All languages benefit from tests...
@snokzor
@snokzor 4 жыл бұрын
It can be too much, at one of my previous jobs the dogmatists wanted to write extensive tests for simple 'fire and forget' apis, including the 'function does exist' tests. I never saw the point in doing that and it complicated everything soo much and made everything slow to a crawl. Never mind that the actual API design was flawed.
@snokzor
@snokzor 4 жыл бұрын
if you redo the thing later it'd make sense to write tests first ..)
@nemanjatrivic9505
@nemanjatrivic9505 2 ай бұрын
I think people are afraid of bdd and unit tests because they probably never tried it. And keep in mind you don't need to do exhaustive unit tests. You just need to cover happy path, one to two tests per function.
@Rizhiy13
@Rizhiy13 4 жыл бұрын
I found TTD is an easy way to delegate work. For me it is much easier to write a few tests that check the behaviour I want and ask my subordinate to write code that makes the tests pass, than to explain to them exactly what I want. Additionally, by making the tests run after every change I make sure that they don't break the functionality in the future.
@lagz89
@lagz89 8 ай бұрын
makes sense
@nexovec
@nexovec 4 жыл бұрын
I'd be more conservative and say that pair programming is an efficient learning strategy and a method of brainstorming
@amodo80
@amodo80 4 ай бұрын
implementing an API feature is the perfect situation for TDD. you do know in advance what you're making, so you could in theory write the test beforehand.
@nonsense402
@nonsense402 7 жыл бұрын
He and most other people are missing the entire point of automated tests. They're not for discovering bugs or assisting with the development, they're for helping identifying regressions when you make changes to an existing system. Sure, if you're going to throw away a bunch of code, it would make sense that you wouldn't necessarily reuse your tests, but if you are maintaining a large system, it makes more sense to catch those bugs early. It costs roughly 10x more to catch a bug in QA than it does in design, and it costs roughly 100x more to catch bugs in production than it does during development. If I can catch bugs in development while I'm working, then that's a great RoI.
@bhart1731
@bhart1731 7 жыл бұрын
You are correct, identifying regressions as the main benefit of unit testing. But you also say they're NOT for discovering bugs, but then contradict yourself with saying how much it costs to catch bugs in QA and Production. The costs that you state are based on what observation or data? I call baloney on your 10X or 100X figures. It is possible in some very rare situations that that would be the case. Companies that do medium to large scale software development already have QA teams and they are more or less a fixed cost regardless of the presence or absence of unit tests. As far as catching bugs in production, that can actually be the cheapest way to find bugs. I would offer as evidence that Microsoft built their Windows empire that way. The tens of thousands of bugs didn't stop people from using Windows. This is not advocating for shipping buggy software. I've seen plenty of very well written software with very few defects or bugs that had zero unit tests. I experimented with unit tests when they were a fairly new thing and didn't end up using them very much. It is like Jonathan says, one doesn't know in advance often what to write tests for. I'm not totally discounting their value but I think they are over valued. Like if one doesn't use them then your code is going to suck, and that is simply not true.
@bhart1731
@bhart1731 7 жыл бұрын
My above comment and this one are for Corbin. I'll also add that it is a good idea to catch bugs in development. And that is why developers should not become dependent on QA to catch bugs for them, but unit testing is not the primary tool to do this, good coding practices and attention to detail and some amount of developer testing is the primary tools. No one knows how something should work better than the developer who wrote the code. Or at least he should know.
@bhart1731
@bhart1731 7 жыл бұрын
they not he.
@joaoedu1917
@joaoedu1917 7 жыл бұрын
He is not against automated tests. So if you implement say a bot that uses your system or play your game thoroughly, it WILL raise issues.
@MatthewHaydenRE
@MatthewHaydenRE 6 жыл бұрын
Top comment, misunderstands what he's saying. He's saying unit tests and TDD are a waste, not testing.
@toopkarcher
@toopkarcher Жыл бұрын
People start using mocking libraries when tests are mandated and then you're just literally writing my code does what I tell it to do via the mocks lmao. I don't know what output it'll actually produce. And when anything changes someone will just have to redo all the mocks or add new ones
@dexvt1862
@dexvt1862 3 ай бұрын
There are tests that work well with TDD. Let's call them pre-feature tests. Then there are tests that work better after features are completed. Let's call them post-feature test. Sample pre-feature test: You already know your login page will have elements, that you by default add whenever you create a project. So you add unit tests to ensure completion of elements. Using the tests almost like a checklist. Sample post-feature test: After completing the login page, you want to ensure that it works and stays that way. So you add an integration test for logging in. You also decided to add e2e that would test the entire login workflow. (And even if you "already know" what elements you want, you probably will still miss some unit tests as well with your pre-feature tests, so you'll also still be creating more unit tests, or updating existing ones 😂) P.S. I'm not a fan of TDD. I do 100% of my unit tests, integration tests, and e2e tests after writing features, and after I'm happy with the outcome of my manual testing.
@sergiorodrigoroyo5079
@sergiorodrigoroyo5079 11 ай бұрын
The problem with Blow is that he's used to small codebases (Braid, for example) that either make money or get abandoned. Real projects out there need tests because the project is going to be ongoing for a decade or longer. So you can't just write & write code until it crumbles and changing the code without regressions becomes difficult. But for that you need to work on real-world projects, not small games.
@MatthewHaydenRE
@MatthewHaydenRE 8 ай бұрын
Braid was 100k sloc. I wouldn't say that was small.
@shakazed
@shakazed 6 жыл бұрын
I agree with most of what Jonathan is saying. The company I'm at has just started implementing TDD and I've yet to see any benefit that compensates for the lack of productivity. What I do see is that it might be a way for new programmers to write cleaner and more compartmentalized modules but for an experienced programmer you probably already know how to structure your code. I also hardly see any use of low level unit tests since 99% of the time the bugs/problems I encounter are in the interactions between modules or in the design of the solution.
@vespuzzi
@vespuzzi Жыл бұрын
Perfect people always do everything alone anyway.
@oblivion_2852
@oblivion_2852 4 жыл бұрын
Testing each and every part of a program has always seemed tedious to me. On the other hand I really like seeing how Factorio does its unit test suite. Basically get a super beefed up computer to go through high level tests to see if all the different sections of behaviour in the game still works. As blow said most of the bugs don't occur at the unit level, they occur between units and higher levels so from what I've seen Factorio goes through and tests basically how the user interacts with the program instead of testing functions in the way that only a programmer would care for or understand
@Titere05
@Titere05 Жыл бұрын
I don't think his take on pair programming is right. I haven't seen anyone claim pp increases productivity, rather than it sacrifices productivity in the name of having the code automatically reviewed. Besides, it's not two people sharing the keyboard and arguing a lot, there's a pilot who implements the thing, and a copilot who is looking out for the meta stuff, such as, does this road the pilot is taking lead down to a problem? Is he naming the variables right? And so on. Of course they can or should switch roles at some point. And I think its main use tbh is pairing a senior with a junior in order to train and supervise the junior, hopefully teaching them good practices
7 жыл бұрын
I am a TDD advocate. I think that Jonathan does not see the benefits of TDD because he is able to get himself longer period of focused work than 20 minutes. I program at work in open office. People are still chatting about something and telling me something. I don't have more than 15 minutes of focused work. The same at home. Children are running around me and want my attention every 5 minutes. And I have to be productive in those conditions. And TDD simply IS the way for me how to get back on track after those distractions. If you have the comfort of having all your mental space just for the development, you can switch contexts between coding, designing, refactoring pretty easily because you have all you need in your head all the time. The tests are in your brain. I will never be as productive as a person without kids working alone in a room with no distractions. But I would never be as productive as I am today with my conditions as I am with TDD.
@darkarchon89
@darkarchon89 6 жыл бұрын
even though it's one day old this is still a severely underrated comment
@pleggli
@pleggli 6 жыл бұрын
Also, some types of programming work is extra suited for full on TDD writing a lot of tests before the implementation. When implementing a protocol from an RFC or similar spec document it's very handy writing a lot of tests based on the spec in chunks before implementing the spec parts which the tests are relevant for.. Also algorithms where you know the expected outcomes are good candidates for doing TDD. I don't normally use TDD but when I do it always makes my work easier and faster because I know I can trust the tests to catch bugs I might accidentally introduce so that I can adjust before the bugs might propagate through other parts of the code as well.
@Microtardz
@Microtardz 6 жыл бұрын
> I program at work in open office. People are still chatting about something and telling me something. I don't have more than 15 minutes of focused work. That sounds like a shit fucking job with terrible expectations out of their employees, and I can only assume that it results in you not programming all that much. I can only assume you're in more of a managerial position and less of a developer position. Because if you aren't, you're probably being horribly underpaid for managerial work. > The same at home. Children are running around me and want my attention every 5 minutes. Teach. Your god damn kids. About personal space. Tell them "Daddy is working, go do something else you little shits." > And TDD simply IS the way for me how to get back on track after those distractions I mostly use comments in code or look at my agenda in emacs, some units tests would still leave me going "Huh, what the fuck was I working on again?".
@WayneBagguley
@WayneBagguley 5 жыл бұрын
If you can't focus on programming for more than 20 minutes at a time then you shouldn't be coding. Don't underestimate how much mental effort, concentration and focus it takes to cut good code. What's bad about TDD? Well, TDD actively encourages technical debt because you are only supposed to write the least amount of code to get a test to pass before writing the next test and going through the cycle again. That code you just wrote will most likely be made useless by the next test so you've just wasted your time. Rinse repeat. Furthermore, TDD actively encourages design debt because it stops you from thinking of the bigger picture. TDD also helps produce poor architectures for the same reason. TDD encourages the use of mocks, which leads to brittle tests; mocks should be used sparingly. The only time I have found a benefit to TDD is when fixing bugs. It's useful to create a test which reproduces the bug before you try to fix it so that you can be confident you've fixed it. The feasibility of this depends on the exact nature of the bug of course but in general it's a good approach to take. Unit tests are great and should be written where prudent, but as for using TDD as your main driver, I agree wholeheartedly with Jonathan Blow.
@themerpheus
@themerpheus 5 жыл бұрын
Cost ? Jonathan develops his games for years. The Witness took 7 fricking years and 6M bucks! It might be because of his disregards to paradigms and writing a lot of code again and again. Best code is the code that you write at once. I respect him, but I disagree.
@okaravan
@okaravan 4 жыл бұрын
With pair programming it would take 14 years and 12 millions. With TDD it would take 28 years and 24 millions. So what exactly you disagree with?
Jonathan Blow on scripting languages
9:30
Jeru Sanders
Рет қаралды 138 М.
Thoughts About Unit Testing | Prime Reacts
11:21
ThePrimeTime
Рет қаралды 243 М.
REAL or FAKE? #beatbox #tiktok
01:03
BeatboxJCOP
Рет қаралды 18 МЛН
小丑女COCO的审判。#天使 #小丑 #超人不会飞
00:53
超人不会飞
Рет қаралды 16 МЛН
Mom Hack for Cooking Solo with a Little One! 🍳👶
00:15
5-Minute Crafts HOUSE
Рет қаралды 23 МЛН
The evil clown plays a prank on the angel
00:39
超人夫妇
Рет қаралды 53 МЛН
🚀  TDD, Where Did It All Go Wrong (Ian Cooper)
1:03:55
DevTernity Conference
Рет қаралды 574 М.
Jonathan Blow was right about the crash of "tech" jobs?
14:11
Blow Fan
Рет қаралды 117 М.
Handmade Hero | Getting rid of the OOP mindset
7:44
vexe
Рет қаралды 116 М.
Test-Driven Development // Fun TDD Introduction with JavaScript
12:55
Jonathan Blow on Refactoring
7:10
Anton Swifton
Рет қаралды 140 М.
Why I Don’t Unit Test
8:25
Theo - t3․gg
Рет қаралды 92 М.
Jonathan Blow on Game Engines
4:44
Blow Fan
Рет қаралды 84 М.
The most important talk on programming by Jonathan Blow
22:55
Not Sure
Рет қаралды 221 М.
Why Would Anyone Hate TDD? | Prime Reacts
46:52
ThePrimeTime
Рет қаралды 154 М.
REAL or FAKE? #beatbox #tiktok
01:03
BeatboxJCOP
Рет қаралды 18 МЛН