Travis EvashkevichTravis Evashkevich Today at 03:00
how do people feel about TDD for py tools/scripts - more so on small tools.
Fabian GeislerFabian Geisler Today at 04:34
Would love to have that, but reality shows that tools are rarely that well defined, that you are able to write tests upfront. I settled with: core libraries are tested and tools are well reviewed (in pull requests and such). Interested what other studios have in place for that
Travis EvashkevichTravis Evashkevich Today at 04:36
Yeah the tech-anim dept are doing heavy unittesting apparently and as much as I want to do TDD, I also don’t think it needs to be done on things like small util scripts for example. I think things that have “dire” consequences when they go wrong (e.g. anim/rig tools come to mind that if things are wonk then they require much bigger clean up in a lot of cases…) would make sense to test on. (edited)
1
Simon LundbergSimon Lundberg Today at 05:10
Test driven development is a scam.
Sorry, I’m only being partially serious.
Travis EvashkevichTravis Evashkevich Today at 05:11
haha, I think for an actual “product” it makes some sense, but I don’t think it makes much diff for tooling that needs to be fixed/dev’d on the fly
Simon LundbergSimon Lundberg Today at 05:11
The issue I have with TDD is that it’s based on the idea that you’ll be better at thinking of edge cases when writing tests than you are while writing code. In my experience, that’s just not the case.
Chris CunninghamChris Cunningham Today at 05:11
anything like this is just breaking down the cost of doing so and its benefits. some thigns are just too small to be worth it or take too large of a recfactor
1
Travis EvashkevichTravis Evashkevich Today at 05:11
yeah that’s always been my argument really.
that and time
Chris CunninghamChris Cunningham Today at 05:12
also i dont really follow a pure TDD like i write code and tests at the same time
like SImon mentioned some tests only exists due to what i seen in the real code that tipped me off to a potention edge case
Simon LundbergSimon Lundberg Today at 05:12
I don’t think testing is a bad idea. But even in a big code base, if I’m writing new functionality I’ll think about edge cases while writing the code. Bugs happen when there are edge cases I hadn’t considered. But this happens in TDD as well, because I can’t write tests for cases I didn’t realize could happen.
Bugs happen because of paths of execution or states happen that the programmer didn’t consider; this is true regardless of methodology, and I don’t think writing the tests first helps you think of more edge cases.
Travis EvashkevichTravis Evashkevich Today at 05:13
yeah exactly. I usually run my tools a bunch of times to make sure they don’t explode and also try to make sure that I handle my edge cases (and as you say, when it falls over it’s usually cause someone fed it something that totally shouldn’t have made it anywhere into the tool haha)
Chris CunninghamChris Cunningham Today at 05:14
often i only write a few tests before hand, which more or less let me know when it works on the ideal golden path
but then a bunch more get added that exist due to how it was implemented and what potential bad states can happen there
and what code paths were not hit yet that i want to be hit
Simon LundbergSimon Lundberg Today at 05:16
I think TDD happened because people are always looking for a magic bullet that will make managing software development not suck.
Chris CunninghamChris Cunningham Today at 05:16
in the planning stage you don’t really think of what library calls you do that could cause a error and how you are going to handle that error
well parts of TDD are good, but its like everything where following a exact set of rules to the tee will never work
you need to leave room in for your experience to be used and to combine everything you know to write better software
Frieder ErdmannFrieder Erdmann Today at 08:43
I think the only reason I’d start with tests immediately is to hold myself accountable to write them at all, and to remind myself (and others) to keep functions separate as much as possible to be able to test them as easy as possible
Travis EvashkevichTravis Evashkevich Today at 08:44
looks like we’re going to allow non t-anim depts to define how they want to dev (following codestyles and general guidelines etc.) so that’s good.
Steve TheodoreSteve Theodore Just now
I’d start tests ASAP.The price we pay for Python’s flexibility is not knowing from one day to the next that things will really work. If you want the freedom to experiment and make changes without terror you need to use tests to nail down the boundaries between modules and the consistency of functions. Especially when you have multiple groups working on things. A “harmless” change to something dumb like string formatting can have unforeseen and hard to debug consequences on the far side of the code base.Basically any code whose output is consumed by other code should have tests, even if they are really dumb like “the output of this function is a number” or “this raises an exception if you feed it a 0”. They are not there to guarantee things work so much as to guarantee they do today what they did yesterday.Testing tools proper – the actual buttons or commands the users get – is not a unit test thing, it’s a real-person thing. Ideally you have a staging distribution you can use to get new things in front of real users w/o having to move the whole team off of a known working build.