Це відео не доступне.
Перепрошуємо.
Why I Write Code Backwards (and Why You Should Too)
Вставка
- Опубліковано 29 сер 2024
- Why would anyone write their tests first and design last? In this video, David Scott Bernstein explains why this seemingly backward approach is actually the key to building flexible, scalable, and maintainable software. Discover the two phases of development-separating the 'what' from the 'how'-and learn how this strategy can lead to better encapsulation, modularity, and testability in your code.
Join David as he shares his insights on:
- The importance of writing tests before coding.
- How to keep your code agile and adaptable.
- The art of translating user stories into effective, test-driven development.
Ready to revolutionize your software development process? Watch now and see why this method produces better code faster.
Software Developer Training and Resources:
- Explore comprehensive courses on software development principles and practices at To Be Agile: ToBeAgile.com
My Developer Essentials Training curriculum shows how to build software using design patterns, refactoring, and test-first development. Contact me (tobeagile.com/...) if you have a group of ten or more software developers and are interested in a private class. If you or a few of you would like to attend one of my public classes then join my mailing list on my Public Training Schedule (tobeagile.com/...) and I will notify you when registration opens for next public class.
- Deepen your understanding with my book, "Beyond Legacy Code: Nine Practices to Extend the Life and Value of Your Software": BeyondLegacyCo...
For AI Enthusiasts:
- Master prompt engineering with "Prompt Engineering for Everyone: A Comprehensive Guide to Unlock the Potential of ChatGPT and AI Language Models". Get your copy on Amazon: www.amazon.com...
Next Video in the Series:
- Check out my channel, @ThePassionateProgrammer for more videos -
/ @thepassionateprogrammer
Your Thoughts Matter:
- Have questions, suggestions, or ideas? Share your thoughts in the comments below. I'm excited to hear from you!
#ThePassionateProgrammer #DavidScottBernstein #SoftwareDevelopment #AIPromptEngineering
I never write tests for my code. Because it is flawless. Always.
I don’t believe you. Humans (and AI) make mistakes. The REAL mistake is being in denial of it!
@@ThePassionateProgrammer Aren´t the other mistakes REAL as well ?
@@ThePassionateProgrammerPretty sure that was humour.
You're missing the point. Tests aren't to validate what you wrote.
They are to clarify what you will write.
@@successengineeringamplio Wrong.
Thanks for the update! Great process!
Also thanks a lot for mentioning the importance of small tests that verify an assumption which you later throw away. I think deleting tests is as important to the design of quality solutions as writing tests is.
Very smart! Yes, only keep tests that create new distinctions. Use assertions to specify behavior! That way your tests become much more valuable.
Yes, please, demo it! :)
How would you approach developing a client app such as Android app. What would you test? And what not. What would be first part you would develop?
Why I like a declarative programing, because I can even end on a stage what, and never touch how. Writing tests also helps you to understand what the system should do.
I feel like this video makes a lot of sense when you already know what he's talking about, but if you haven't lived it or been in these situations enough it can be cryptic.
Yeah, I was keeping up until sometime around the half way point, I think... Vocabulary expanded suddenly... Then we were talking APIs... Method signatures.... Etc... Wish the example stayed simple or connected the dots (probably left on the cutting room floor due to the algo).
This video was wildly helpful to me. Thank you 🙏🏾
I am so glad. You are welcome!
I really enjoyed this video and approach. You've given the most comprehensive yet sussinct introduction to the mindset (and working theory) behind good TDD I've yet encountered. I've consumed endless content on the matter in the form of courses, articles, and videos, and nothing really motivated me to incorporate TDD into my practice like this video. Most content does a decent job of explaining the what/why and maybe the how from a technical standpoint, but I love how you provide a clear path on how to approach the mindset from a practical perspective. Thank you for the insight. I will try this approach on the project I am just starting.
I deeply appreciate your comment. Thank you!
Waiting for the Demo!
TL;DW testing individual components only makes sense for libraries to see if the details are logically sound (most common testing done today) such as having a class named MathTest
What the most common testing should be is Given-When-Then output mappings for the given inputs in a class named BusinessClassTest without major concern for details before implementation
If you are testing behaviors using GWT then you are doing many things correctly. You are thinking about your component as having a single responsibility that you can easily set up, trigger, and validate. Bravo! That’s the way to build software!
Step 1: Fix the economy so memory becomes cheap, it's literally just printed nowadays anyways.
Step 2: Treat binary bits as a 4D array, scrap the old memory systems.
Step 3: Bring programming closer to dealing with real data. When you move a photo on your screen, you're moving it in ram as it would be on screen. Saved in memory the same way, as a physical array of bytes.
Step 4: Since memory is now places, programs and objects can be allocated their own processors
Step 5: create a laptop that has multiple processors all running 1.5ghz, 24 cores each. Load balance objects by their methods to run accross cores since each object has a defined space in memory so you dont need to be limited by memory accessing resources.
step 6: Realize where objects are has to be a fixed location in a logically accessible space and that not doing so is what cripples our progress with computer science
Step 6: Realize you didn't finish your computer science degree
Don’t let missing Step 6(a) hold you back. Let’s of great developers don’t have CS degrees (including me).
@@ThePassionateProgrammer I mean, I haven't, It's just been a process of evaluating how low level I'd have to go to create the database structure and whether that structure would be feasible for one person to create. I wish there was a way to get funding/have someone evaluate the concepts without risking them bein' stolen
On thing I'm going to try you talked about is starting simple. Then if simple doesn't work, look to design patterns.
Starting with grand architecture and design patterns leaves me in coder's block, unable to write any code because I've got no clue what to do
Yes, start simple and build incrementally, that’s exactly what I’m saying. Or in Kent Beck’s words, “Do the simplest thing that could possibly work.” Once it is working it’s much easier to build upon. Big up front design is Waterfall and a waste at many levels. Incremental software construction is a core idea behind Agile. So, they did not teach you this in school? What did they teach you about code quality, software principles, acceptance testing, design patterns, and refactoring? These are what I consider to be core skills for software developers.
Thank you for this video. What would you say is the ratio between the time you spend specifying what to do and actually doing it?
How do you test things that go to a database for example? Do you "mock" it? I'm not a big fan of that, rather build an in memory version of a DB which I guess is just a more complicated way of mocking things and I guess I'd need tests for the test implementation.
Good questions. It’s hard to answer the proportion of analysis (what) verses design (how) I do because it is ongoing and iterative. I probably spend twice as much time in analysis, talking to users, creating acceptance tests, getting feedback, etc. versus coding in the beginning of a project and that proportion reverses towards the end of a project.
Regarding your second question: How to remove dependencies so that your tests test only your code is the subject of many videos and I hope to make some of them. Yes, the short answer is to ‘mock’ the database so it is out of the test but that doesn’t mean to use a mocking framework. Mocking frameworks are slow and add a level of complexity that I find distracting. Creating my own fakes and injecting them is super-easy while promoting clean code habits that make code more testable and extensible. I’m all in favor of automation but mocking is one area I prefer to do by hand. Are you familiar with techniques around dependency injection and creating ‘hand-crafted mocks’? If not then I can make a video about it.
Thanks for the video! I'm going to try to apply some of these actions in my daily life, let's see how it goes.
Brazilian greetings o/
Great, best of luck!
15:35 I still don't see the value of TDD if you still expect to have a pile of bugs. I see the value in tests, but not testing first if you end up in the same place with as other strategies.
You also end up with a lot of wasted time rewriting tests when you need to rewrite something because of moving goals or needing to re-architect something. Even with properly decoupled code and forethought, I think TDD is a good idea but in most environments it's a lot of overhead - as you might end up just throwing code away - including the tests.
Client asks for feature x
You write your test, then your code
Client no longer wants feature x-
Any time writing tests is now wasted.
As you develop incrementally, you'd have probably moved on from feature x to another feature. (unless you wrote a test straight after in which case you're in the same boat anyway)+
I think an "abstract" test could be useful - a template of the code what you think the test might look like in the end without the logic
@@anthonyhawkes4101 You can still write tests for things that are unlikely to change soon or for critical pieces. Debugging is a lot of time thrown away as well, and TDD can help reduce the amount of debugging.
You might end up in the same place as with other strategies, but I personally end up in a much better place design-wise and I definitely get there faster. I also find it a lot more fun since I've gotten there in a way that has given me about 20 dopamine shots of success instead of one dopamine shot at the end.
So I get to higher quality faster and have more fun. Good enough for me.
Now I don't always do TDD. If I'm building a website e.g., I get this rapid iteration from just hacking css in the browser, which I then copy to the css files in the project. It's not strictly TDD but it's essentially the same process. I have a hypothesis, I test it & I apply it.
@@anthonyhawkes4101 Time spent on tests that are thrown away is definitely not wasted. You've used the creation of the test to verify the design of your API and used it to structure your thoughts on what your code has supposed to do. This is very powerful in directing your mental model in a way that improves the design of the solution.
As a matter of fact I delete a significant amount of tests I write regardless on whether a feature is sunsetted or not. As during my design process, there are different slices of functionality I want to test, but when the production code has reached a satisfactory state I will reassess my test suite and remove or merge redundantly overlapping slices. Keeping your test suite manageable is part of delivering quality code.
Great answer! Well said.
If you're not completely familiar with the codebase and business logic, starting with the tests is a waste of time. Sure, you could do it, but you'll be constantly updating them during implementation.
You have an inaccurate perspective on what test-driven development is about and how it is practiced. No wonder it doesn’t work for you!
Constant iteration incremental change can be a very positive approach. It actually happens in any code base when the program becomes big, anyway. So why try to avoid it? Our thinking should evolve along with the creation of our program, why not!
@@gauravtejpal8901 well said, thank you!