❤️ Consider supporting this channel by becoming a Patron: www.patreon.com/infalliblecode

@somerandomchannel382

Жыл бұрын

is the heart container asset or unity project code available?

One thing you glossed over here and that really tripped me up just getting started (thanks for the lack of docs, Unity) is that tests must be in an Editor directory. You created your file outside, but then realized your mistake and fixed it but never mentioned it. If you miss the one second where you fix the mistake, you're left scratching your head.

I look forward to more videos.Keep it up!

@InfallibleCode

7 жыл бұрын

+MisterBassBoost thank you!

really good video, thanks.

Ready to shake and bake! Seriously though, great set of tutorials so far. Also appreciate the vim usage.

@InfallibleCode

6 жыл бұрын

Heck yeah, shake and bake! Thanks for watching, man. Oh and glad that you caught and appreciate the vim usage! Are you a fellow vim user?

@recursion27

6 жыл бұрын

Absolutely. Frustrating coworkers and all (they just don't get it).

If, one day, in game development I get 5 years to complete a mid-sized project, I will happily implement test driven development. Until then, Debug.Log and the old "eyeball" will do fine.

Thank you very much for these tutorials! They are very informative and interesting

you are a great help man , thanx :)

@InfallibleCode

6 жыл бұрын

+Διονυσιος Ασημακοπουλος glad to help!

I tend to write my code first, in a messy fashion, with enormous methods etc. Then I start writing tests, which requires refactoring of this code. And by refactoring the code to be testable, it also becomes a lot cleaner and more structured. What's your though on developing in this fashion?

@chris.dillon

5 жыл бұрын

If you are listening to what your tests are telling you (it's hard to test, is a mess) then that's the Driven part of "TDD". If you just write your tests first, that's just Test-First. It's just names but the style is important.

@antdok9573

Жыл бұрын

I think the biggest difference between these two approaches is that the size of your change will be larger in writing production code first rather than test code first. There's not much that will remind you to work incrementally until you start writing a failing test and focus on fixing that first.

You mentioned a blog post by 'Phil Hack'. I can't seem to find a link to it...

Great series bro! 6yrs later it is still difficult to find good unity tutorials on intermediate level topics.

Great video, and I am loving the content. I have a recommendation for the design of the Replenish method. Instead of throwing an exception because the consumer passed in a negative value, you could instead change the parameter type to be an unsigned integer. If I am working with some code and I see that it accepts an int as input, I dont think it is reasonable to expect that method to throw an exception for any possible value of the integer. if you can't deal with negative numbers, tell me so by encoding that fact into the signature of the method, and make the illegal state unrepresentable by utilising the type system.

I posted a response to Emrah Ozer's comment but he seems to have deleted it almost immediately afterwards. In short - ignore those criticisms. They are misguided and the video demonstrates a better grasp of TDD than the comment. Particularly his first point, which promotes breaking encapsulation by exposing internal state of the unit and limiting the validity of the test by not actually testing the state of the object where it is actually meaningful (the Image). Additionally, a TDD purist would tell you that generalising your test case is a step to take _after_ the pattern emerges (i.e. separate tests for separate test cases is perfectly fine initially). This is one of the better TDD videos I have seen to date.

@InfallibleCode

6 жыл бұрын

I appreciate this comment. I've come to learn that TDD can be a controversial topic to cover, and many developers have their own opinions about how to conduct the process correctly. I've read many of books, tutorials, and articles on the subject and what I do in these videos is the flavor that I've grown accustomed to doing. My goal for this series was to actually demonstrate TDD in game development, which is something I hadn't seen before. It's comments like these that reaffirm what I'm doing. So thank you very much!

@planteh

6 жыл бұрын

No worries! It's something I'm looking at the minute, too, as a programmer now dabbling with game dev. What I'm finding is that in some scenarios you can assert directly against the GameObject state and that's ideal, but in other situations (particularly dealing with things like procedurally defined transform positions - think tilemaps etc.) the desired GameObject state is more ambiguous/hard to define. In these scenarios you can treat the MonoBehaviour as a "renderer" and provide a fake implementation (or a mock) for testing (e.g. tileMap.DrawTo(fakeRenderer)), then have the MonoBehaviour pass itself as the real implementation (tileMap.DrawTo(this)) and use the TDD-driven "renderer" interface to generate the methods required to map "logic space" to "game space." Interesting topic!

@exetamin

6 жыл бұрын

My comment is still there, I haven't seen the notification to be honest. Testing the view is wrong because you may change the view. Later on rather than having a simple image, you may create a custom view which has animations between states controlled by the animator etc. In that case you would not have an image.fillAmount and all of the tests you wrote specifically for that view would be invalid. If you write the same tests pointing to progress you would still have valid tests. In your own time please investigate mvvm pattern.

@Gryphonheart

5 жыл бұрын

I can agree with wholeheartedly on that about being wrong to test the View. However something must be noticed beforehand, the view is well defined in most patterns and frameworks for System Development, not so much for game development since the view is a lot bigger and more complex. From what I know of TDD you keep tests out of the View becuase of entropy - the view is much more mutable than the controllers, it could change many times over the development. In Game Dev, most of everything is very mutable. I've been working as a Game Dev for 4 years and features come, go and change over time to adapt to either the Game Designer's whim or the fun factor testing's whim. Such complaints are very common. And that is why TDD is rather rare in this evironment. Yet, make no mistake. Big corps would hire you to write TDD game code often despite the entropy and would demand you the same productivity. This is one of the reasons why it is said to be so stressing and many migrations from these corps occur. That being said, I really like the video's approach to TDD on Unity as it is less constraining, more factual.

Hey, I have a nice challenge for you... Try to do the Zelda Botw climbing system.

TDD is sometimes funny. The code is now at least 5 times longer, but still has errors. For instance, pass in a fillAmount of 1.0f. Still a good video. May I ask why you don't put your tests in their own assembly?

Any chance of a text transcription of this? It's a lot easier to follow.

please upload next video.. good stuff btw

@InfallibleCode

7 жыл бұрын

+Kelly Sampson next video will be out within the week! Thanks for watching!

Great video and bookmarked, will be great if you can publish a book, by any chance, so we can put it on the shelf and let the junior read them!

What I hate about these is... 99% of the game code is NOT calculating points and NOT some sort of i/o. most of a game is complex real time behaviours. How do you test whether a ball bounces correctly? It's just one monobehaviour, with no public API.

7:12

Good tutorial. I'd like to add that nesting classes isn't the most common approach. Usually best practice is to have one class per file, only nest when it makes sense. Also, a class should not be called a method, that's just confusing. I don't have much experience with TDD so maybe naming practices are different.

The link for the blog post in the description is broken.

@InfallibleCode

6 жыл бұрын

Thanks for letting me know. I've updated it.

I might be new to programming, but i dont see the reason why u made several methods for diffrent values, why not make one dynamic method that can take in any kind of heartpieces. And why would you test such easy code anyway? why not write the methods and then debug if it doest work as expected? Thanks :)

@InfallibleCode

7 жыл бұрын

+Thekalllllllll thank you for watching! To answer your questions: creating multiple test methods allows me to test different input values and prove that my method is working as expected. Test-Driven Development is a development process that I'm demonstrating throughout this series, and that process dictates that you only add code that fixes a failing test, no matter how easy that code may be. The idea behind TDD is that the upfront cost of adding tests is outweighed by the long term benefits. I definitely recommend reading up on it to see if the process is for you. Or you can just keep watching my series ;P

@Thekalllllllll

7 жыл бұрын

I will defo keep watching, see if the dime drops for me at some point :D

I have not expect to meet one of my favourite Unity developers as a first in youtube search "Unity Test Driven Development" with complete playlist of examples. I am still cannot realize that you have somehow hidden such treasure.

First of all, I really appreciate the effort. Being said, I think it would have been better if you were a bit more experienced in testing before creating tutorials about it. Even though there's not too much code, you somehow managed to create several major mistakes which also propogated in your other videos. - All of your assertions done to the image's fill amount. Image is the rendering of the heart, which is the VIEW. You shouldn't test the view nor you shouldn't have references to the view in your tests. There are some usecases that can be justified but not in this case. You could have avoid Image, GameObject, MonoBehavior dependencies easily by just introducing progress variable to the heart and testing that. - Writing assertion first is a terrible thing to show to the newbies. To write the assertion first, you need to give too many decisions in one line (like variable names etc). Writing it as a comment would be fine if you can't literally keep your goal in your mind for 30 secs, but coding it from backwards and fighting with the ide is definitely shouldn't be promoted in this level of tutorials. It may be your personal choice, but again teaching is something different. You need to be aware of the bad habits you're introducing. - Your test names are hard to read, and out of any convention I know of. By seperating every word with underscore you make the readers life quite miserable. Here's a well known list of naming conventions: dzone.com/articles/7-popular-unit-test-naming _1_Sets_Image_With_0_Fill_To_25_Percent_Fill -->thish could have easily written as --> Replenish_SetsFill25Percent_IfCalledOnce - Which brings us to another thing, if you later on decide to have 5 steps in your heart instead of 4 steps. You literally need to change every test name and every assertion. That's a great example of how to not to write tests. - Instead of writing the same test over and over again just to change the input values, you could have used values attribute of NUnit. Which would help to get rid of 2 repetitive methods. github.com/nunit/docs/wiki/Values-Attribute Even though it's a basic one I think using values attributes is a pretty important one, because when people are trying to learn TDD, or testing in general, they have prejudice about the amount of burden it brings. In your example it seems testing is quite intimitating and doesn't provide any benefits. A newcomer will instantly say: he wrote 3 methods to cover one method and god knows how many methods he needs to write to cover the edge cases also. It's common that you need to write more tests then production code, but all of those needs to have a purpose. Yours just tests same functionality with different values. Anyways I know I sounded a bit harsh but I think one of the biggest problems of Unity ecosystem is, the lack of good quality tutorials (even the official ones). Whole internet is full of bad coding practices. That's why I wanted to take time and comment on this. Again I appreciate the effort, but I think it was an early step for you to take.

@planteh

6 жыл бұрын

These are not good criticisms. In particular, your first point. Asserting on the image is perfectly legitimate: the image exhibits the meaningful state that you actually care about and - in fact - asserting on the image actually promotes good encapsulation in the heart. Exposing a property on the heart and asserting on that would break encapsulation (think "tell, don't ask,") and actually limits the validity of the test: the internal state of the heart is not important - the impact on the game state is what matters and this is not covered by asserting on some exposed public state in the heart. Alternatively, abstract the image behind an `IHealthView` or similar and use a fake as a test double, but honestly that is a premature abstraction when (a) testing the actual state of the image is so trivial and (b) no other implementations/polymorphism are needed. On test duplication - generalisation of test cases is (from a TDD purist point of view) something that should happen _after_ the patterns have emerged. That seems to be beyond the scope of this video. As a software engineer who has been using TDD on a daily basis for a good while, this is actually one of the better quality TDD videos I've seen and my instinct would be that the author of the video actually has a fairly solid grasp of TDD in practice.

@WannabeCanadianDev

6 жыл бұрын

Can you elaborate on not testing the view; presumably the point of writing tests is to get you to write code and using that to guide and motivate you. How do we handle the view; and by progress variable to heart, how would the test look instead.

@exetamin

6 жыл бұрын

I've replied to planteh another comment. Which is as follows: "Testing the view is wrong because you may change the view. Later on rather than having a simple image, you may create a custom view which has animations between states controlled by the animator etc. In that case you would not have an image.fillAmount and all of the tests you wrote specifically for that view would be invalid. If you write the same tests pointing to progress you would still have valid tests." For your second question, if you want to check if the progress has been reflected to image fill amount. You can write another unit test for that. So all of your logic related tests would target the progress but just one test would test if the progress changes has been reflected on image.fillAmount. So later on if you change your presentation, you would change just one test.

@pikmin4000

5 жыл бұрын

Why are assertions bad?

The blockpost link routes to scam

Hello, this is currently the first video in your channel, but still it’s not beginner friendly. How do I get to this level? Please I need to know. NUnit. Framework namespace? I don’t even know what that is.