▲ 537 ▼ Uncle Bob becoming even worse: (europe.pub) submitted 3 months ago by ZILtoid1991@lemmy.world to c/programmer_humor@programming.dev 216 comments fedilink hide all child comments
[–] carrylex@lemmy.world 18 points 3 months ago (9 children) Translates to: "I created this (unit) test that tests code that does not exist yet..." Alright AI bro keep your copium... permalink fedilink source hideshow 9 child comments replies: [–] 3abas@lemmy.world 21 points 3 months ago (8 children) Test driven development is not a new concept... permalink fedilink source parent hideshow 8 child comments replies: [–] UnderpantsWeevil@lemmy.world 12 points 3 months ago (7 children) Designing your unit tests before you've written your algorithm is - in my experience - a bit ass backwards. permalink fedilink source parent hideshow 7 child comments replies: [–] vanillama@programming.dev 2 points 3 months ago (6 children) Agreed, you find the right shape for the code as you build and try stuff, adding the tests right after makes most sense, unless maybe you're just testing an API or something permalink fedilink source parent hideshow 6 child comments replies: [–] Zannsolo@lemmy.world 3 points 2 months ago (5 children) I mean I'm theory for any planned method you would know the input and expected output before the coffee is written. permalink fedilink source parent hideshow 5 child comments replies: [–] ThirdConsul@lemmy.zip 1 point 2 months ago (3 children) Except that then you'll shape your interfaces to drive tests nicely, instead of being, you know, sane and useful (been there, done that). permalink fedilink source parent hideshow 3 child comments replies: [–] 3abas@lemmy.world 0 points 2 months ago (2 children) Unit tested test for accuracy, if your code isn't "shaped to drive tests nicely", it's bad code. They enforce requirements. You do start with code, you start with the "shape", you architect how your application should be developed and you write unit tests for the functions you already know you want but haven't written the logic to yet, the unit test validates the logic so you don't spend 2 hours hunting down a missing negative sign. permalink fedilink source parent hideshow 2 child comments replies: [–] ThirdConsul@lemmy.zip 0 points 2 months ago* (1 child) Read my comment again, instead of half way through. permalink fedilink source parent hideshow 1 child comment replies: [–] 3abas@lemmy.world 1 point 2 months ago I did, and I responded to your comment in its entirety. If there's a point you made that I missed, try rephrasing it instead of being snarky... Unit tests tests known facts and validate requirements, good unit tests are defined after you define your requirements and as you design your infrastructure, not after you write your code. They ensure your code does what you require it to do. I don't know what part of your comment I missed reading... permalink fedilink source parent [–] vanillama@programming.dev 1 point 2 months ago As I said, an interface can easily be tested, but if it's internal implementation I normally make a design, implement it, and I usually come up with other ideas and I like having the fluidity of making changes as I prototype and such, that way I'm not constrained by a test yet. After I'm done, and documented my choices if necessary, then I add the tests. permalink fedilink source parent
[–] 3abas@lemmy.world 21 points 3 months ago (8 children) Test driven development is not a new concept... permalink fedilink source parent hideshow 8 child comments replies: [–] UnderpantsWeevil@lemmy.world 12 points 3 months ago (7 children) Designing your unit tests before you've written your algorithm is - in my experience - a bit ass backwards. permalink fedilink source parent hideshow 7 child comments replies: [–] vanillama@programming.dev 2 points 3 months ago (6 children) Agreed, you find the right shape for the code as you build and try stuff, adding the tests right after makes most sense, unless maybe you're just testing an API or something permalink fedilink source parent hideshow 6 child comments replies: [–] Zannsolo@lemmy.world 3 points 2 months ago (5 children) I mean I'm theory for any planned method you would know the input and expected output before the coffee is written. permalink fedilink source parent hideshow 5 child comments replies: [–] ThirdConsul@lemmy.zip 1 point 2 months ago (3 children) Except that then you'll shape your interfaces to drive tests nicely, instead of being, you know, sane and useful (been there, done that). permalink fedilink source parent hideshow 3 child comments replies: [–] 3abas@lemmy.world 0 points 2 months ago (2 children) Unit tested test for accuracy, if your code isn't "shaped to drive tests nicely", it's bad code. They enforce requirements. You do start with code, you start with the "shape", you architect how your application should be developed and you write unit tests for the functions you already know you want but haven't written the logic to yet, the unit test validates the logic so you don't spend 2 hours hunting down a missing negative sign. permalink fedilink source parent hideshow 2 child comments replies: [–] ThirdConsul@lemmy.zip 0 points 2 months ago* (1 child) Read my comment again, instead of half way through. permalink fedilink source parent hideshow 1 child comment replies: [–] 3abas@lemmy.world 1 point 2 months ago I did, and I responded to your comment in its entirety. If there's a point you made that I missed, try rephrasing it instead of being snarky... Unit tests tests known facts and validate requirements, good unit tests are defined after you define your requirements and as you design your infrastructure, not after you write your code. They ensure your code does what you require it to do. I don't know what part of your comment I missed reading... permalink fedilink source parent [–] vanillama@programming.dev 1 point 2 months ago As I said, an interface can easily be tested, but if it's internal implementation I normally make a design, implement it, and I usually come up with other ideas and I like having the fluidity of making changes as I prototype and such, that way I'm not constrained by a test yet. After I'm done, and documented my choices if necessary, then I add the tests. permalink fedilink source parent
[–] UnderpantsWeevil@lemmy.world 12 points 3 months ago (7 children) Designing your unit tests before you've written your algorithm is - in my experience - a bit ass backwards. permalink fedilink source parent hideshow 7 child comments replies: [–] vanillama@programming.dev 2 points 3 months ago (6 children) Agreed, you find the right shape for the code as you build and try stuff, adding the tests right after makes most sense, unless maybe you're just testing an API or something permalink fedilink source parent hideshow 6 child comments replies: [–] Zannsolo@lemmy.world 3 points 2 months ago (5 children) I mean I'm theory for any planned method you would know the input and expected output before the coffee is written. permalink fedilink source parent hideshow 5 child comments replies: [–] ThirdConsul@lemmy.zip 1 point 2 months ago (3 children) Except that then you'll shape your interfaces to drive tests nicely, instead of being, you know, sane and useful (been there, done that). permalink fedilink source parent hideshow 3 child comments replies: [–] 3abas@lemmy.world 0 points 2 months ago (2 children) Unit tested test for accuracy, if your code isn't "shaped to drive tests nicely", it's bad code. They enforce requirements. You do start with code, you start with the "shape", you architect how your application should be developed and you write unit tests for the functions you already know you want but haven't written the logic to yet, the unit test validates the logic so you don't spend 2 hours hunting down a missing negative sign. permalink fedilink source parent hideshow 2 child comments replies: [–] ThirdConsul@lemmy.zip 0 points 2 months ago* (1 child) Read my comment again, instead of half way through. permalink fedilink source parent hideshow 1 child comment replies: [–] 3abas@lemmy.world 1 point 2 months ago I did, and I responded to your comment in its entirety. If there's a point you made that I missed, try rephrasing it instead of being snarky... Unit tests tests known facts and validate requirements, good unit tests are defined after you define your requirements and as you design your infrastructure, not after you write your code. They ensure your code does what you require it to do. I don't know what part of your comment I missed reading... permalink fedilink source parent [–] vanillama@programming.dev 1 point 2 months ago As I said, an interface can easily be tested, but if it's internal implementation I normally make a design, implement it, and I usually come up with other ideas and I like having the fluidity of making changes as I prototype and such, that way I'm not constrained by a test yet. After I'm done, and documented my choices if necessary, then I add the tests. permalink fedilink source parent
[–] vanillama@programming.dev 2 points 3 months ago (6 children) Agreed, you find the right shape for the code as you build and try stuff, adding the tests right after makes most sense, unless maybe you're just testing an API or something permalink fedilink source parent hideshow 6 child comments replies: [–] Zannsolo@lemmy.world 3 points 2 months ago (5 children) I mean I'm theory for any planned method you would know the input and expected output before the coffee is written. permalink fedilink source parent hideshow 5 child comments replies: [–] ThirdConsul@lemmy.zip 1 point 2 months ago (3 children) Except that then you'll shape your interfaces to drive tests nicely, instead of being, you know, sane and useful (been there, done that). permalink fedilink source parent hideshow 3 child comments replies: [–] 3abas@lemmy.world 0 points 2 months ago (2 children) Unit tested test for accuracy, if your code isn't "shaped to drive tests nicely", it's bad code. They enforce requirements. You do start with code, you start with the "shape", you architect how your application should be developed and you write unit tests for the functions you already know you want but haven't written the logic to yet, the unit test validates the logic so you don't spend 2 hours hunting down a missing negative sign. permalink fedilink source parent hideshow 2 child comments replies: [–] ThirdConsul@lemmy.zip 0 points 2 months ago* (1 child) Read my comment again, instead of half way through. permalink fedilink source parent hideshow 1 child comment replies: [–] 3abas@lemmy.world 1 point 2 months ago I did, and I responded to your comment in its entirety. If there's a point you made that I missed, try rephrasing it instead of being snarky... Unit tests tests known facts and validate requirements, good unit tests are defined after you define your requirements and as you design your infrastructure, not after you write your code. They ensure your code does what you require it to do. I don't know what part of your comment I missed reading... permalink fedilink source parent [–] vanillama@programming.dev 1 point 2 months ago As I said, an interface can easily be tested, but if it's internal implementation I normally make a design, implement it, and I usually come up with other ideas and I like having the fluidity of making changes as I prototype and such, that way I'm not constrained by a test yet. After I'm done, and documented my choices if necessary, then I add the tests. permalink fedilink source parent
[–] Zannsolo@lemmy.world 3 points 2 months ago (5 children) I mean I'm theory for any planned method you would know the input and expected output before the coffee is written. permalink fedilink source parent hideshow 5 child comments replies: [–] ThirdConsul@lemmy.zip 1 point 2 months ago (3 children) Except that then you'll shape your interfaces to drive tests nicely, instead of being, you know, sane and useful (been there, done that). permalink fedilink source parent hideshow 3 child comments replies: [–] 3abas@lemmy.world 0 points 2 months ago (2 children) Unit tested test for accuracy, if your code isn't "shaped to drive tests nicely", it's bad code. They enforce requirements. You do start with code, you start with the "shape", you architect how your application should be developed and you write unit tests for the functions you already know you want but haven't written the logic to yet, the unit test validates the logic so you don't spend 2 hours hunting down a missing negative sign. permalink fedilink source parent hideshow 2 child comments replies: [–] ThirdConsul@lemmy.zip 0 points 2 months ago* (1 child) Read my comment again, instead of half way through. permalink fedilink source parent hideshow 1 child comment replies: [–] 3abas@lemmy.world 1 point 2 months ago I did, and I responded to your comment in its entirety. If there's a point you made that I missed, try rephrasing it instead of being snarky... Unit tests tests known facts and validate requirements, good unit tests are defined after you define your requirements and as you design your infrastructure, not after you write your code. They ensure your code does what you require it to do. I don't know what part of your comment I missed reading... permalink fedilink source parent [–] vanillama@programming.dev 1 point 2 months ago As I said, an interface can easily be tested, but if it's internal implementation I normally make a design, implement it, and I usually come up with other ideas and I like having the fluidity of making changes as I prototype and such, that way I'm not constrained by a test yet. After I'm done, and documented my choices if necessary, then I add the tests. permalink fedilink source parent
[–] ThirdConsul@lemmy.zip 1 point 2 months ago (3 children) Except that then you'll shape your interfaces to drive tests nicely, instead of being, you know, sane and useful (been there, done that). permalink fedilink source parent hideshow 3 child comments replies: [–] 3abas@lemmy.world 0 points 2 months ago (2 children) Unit tested test for accuracy, if your code isn't "shaped to drive tests nicely", it's bad code. They enforce requirements. You do start with code, you start with the "shape", you architect how your application should be developed and you write unit tests for the functions you already know you want but haven't written the logic to yet, the unit test validates the logic so you don't spend 2 hours hunting down a missing negative sign. permalink fedilink source parent hideshow 2 child comments replies: [–] ThirdConsul@lemmy.zip 0 points 2 months ago* (1 child) Read my comment again, instead of half way through. permalink fedilink source parent hideshow 1 child comment replies: [–] 3abas@lemmy.world 1 point 2 months ago I did, and I responded to your comment in its entirety. If there's a point you made that I missed, try rephrasing it instead of being snarky... Unit tests tests known facts and validate requirements, good unit tests are defined after you define your requirements and as you design your infrastructure, not after you write your code. They ensure your code does what you require it to do. I don't know what part of your comment I missed reading... permalink fedilink source parent
[–] 3abas@lemmy.world 0 points 2 months ago (2 children) Unit tested test for accuracy, if your code isn't "shaped to drive tests nicely", it's bad code. They enforce requirements. You do start with code, you start with the "shape", you architect how your application should be developed and you write unit tests for the functions you already know you want but haven't written the logic to yet, the unit test validates the logic so you don't spend 2 hours hunting down a missing negative sign. permalink fedilink source parent hideshow 2 child comments replies: [–] ThirdConsul@lemmy.zip 0 points 2 months ago* (1 child) Read my comment again, instead of half way through. permalink fedilink source parent hideshow 1 child comment replies: [–] 3abas@lemmy.world 1 point 2 months ago I did, and I responded to your comment in its entirety. If there's a point you made that I missed, try rephrasing it instead of being snarky... Unit tests tests known facts and validate requirements, good unit tests are defined after you define your requirements and as you design your infrastructure, not after you write your code. They ensure your code does what you require it to do. I don't know what part of your comment I missed reading... permalink fedilink source parent
[–] ThirdConsul@lemmy.zip 0 points 2 months ago* (1 child) Read my comment again, instead of half way through. permalink fedilink source parent hideshow 1 child comment replies: [–] 3abas@lemmy.world 1 point 2 months ago I did, and I responded to your comment in its entirety. If there's a point you made that I missed, try rephrasing it instead of being snarky... Unit tests tests known facts and validate requirements, good unit tests are defined after you define your requirements and as you design your infrastructure, not after you write your code. They ensure your code does what you require it to do. I don't know what part of your comment I missed reading... permalink fedilink source parent
[–] 3abas@lemmy.world 1 point 2 months ago I did, and I responded to your comment in its entirety. If there's a point you made that I missed, try rephrasing it instead of being snarky... Unit tests tests known facts and validate requirements, good unit tests are defined after you define your requirements and as you design your infrastructure, not after you write your code. They ensure your code does what you require it to do. I don't know what part of your comment I missed reading... permalink fedilink source parent
[–] vanillama@programming.dev 1 point 2 months ago As I said, an interface can easily be tested, but if it's internal implementation I normally make a design, implement it, and I usually come up with other ideas and I like having the fluidity of making changes as I prototype and such, that way I'm not constrained by a test yet. After I'm done, and documented my choices if necessary, then I add the tests. permalink fedilink source parent