Friday Facts #366 - The only way to go fast, is to go well!

[FactorioBot]

Here it is! (beep boop)

https://factorio.com/blog/post/fff-366

[BlacKcuD]

No matter if you only plan to start learning to code someday or if you are a senior IT person with years of job experience: Uncle Bob can teach you something.

If you didn't watch these videos before or haven't even heard of Uncle Bob before: DO IT NOW!

[BlueTemplar]

Those seem great, and I'm certainly going to watch those 8.5 hours, but for now the question remains :

Fig.4 - TDD - Test driven development

I have to admit, that I didn't know what TDD really was until recently. I thought that it is some nonsense, because it sounds really impractical and unrealistic to first write all the tests for some feature (without the ability to try it or even compile it), and then try to implement something that satisfies it.

But that is not TDD, and it had to be shown to me in a "for dummies" way for me to realize how wrong I was.

So after the "AHA" moment of realizing what TDD really is, I started to be instant fan. I'm now putting a lot of effort to try to follow the TDD methodology as much as possible, and to force it on others in the team as well. It feels slower, to write tests even for simple pieces of logic that just bound to be right, but the test proved me wrong several times already, and prevented annoying low-level debugging sessions in the near future.

(emphasis mine)

So, what is TDD, if not this ?

[kovarex]

Those seem great, and I'm certainly going to watch those 8.5 hours, but for now the question remains :

Fig.4 - TDD - Test driven development

I have to admit, that I didn't know what TDD really was until recently. I thought that it is some nonsense, because it sounds really impractical and unrealistic to first write all the tests for some feature (without the ability to try it or even compile it), and then try to implement something that satisfies it.

But that is not TDD, and it had to be shown to me in a "for dummies" way for me to realize how wrong I was.

So after the "AHA" moment of realizing what TDD really is, I started to be instant fan. I'm now putting a lot of effort to try to follow the TDD methodology as much as possible, and to force it on others in the team as well. It feels slower, to write tests even for simple pieces of logic that just bound to be right, but the test proved me wrong several times already, and prevented annoying low-level debugging sessions in the near future.

(emphasis mine)

So, what is TDD, if not this ?

Yea, I kind of missed that, I just added a small paragraph there, thanks for the notice. We don't have automated tests for text creation so far ...

[BlueTemplar]

Maybe for 2.0 ?

EDIT : Also, no automated spellchecking, "swithing"
(Also, the "discuss on our forums" button now points to the wrong thread ??)

EDIT2 :

TDD actually is the constant fast swithing between extending the tests and making them pass continously. So as you write tests, you write code to satisfy them basically at the same time. This allows you to instantly test what you write, and mainly use tests as specifiation of what the code should acctually do, which guides the thought process to make you think about where you are headed to, and to write code that is more structured and testable from the very beginning.

Yeah, this seems to be a quite interesting methodology, I'm going to try it out, thanks !

[AnarCon]

ah.... 0.6 i remember thee foundly

[Amarula]

The only way to go fast is to go well.

Thank you for another engaging FFF! It is such a pleasure reading about programming challenges. I always love getting a peek behind the scenes of how you make and keep Factorio the gold standard of game quality.

[eradicator]

I tried to search if others use the dependencies as well, and how they do it, and I surprisingly didn't find anything.

While my library mod is far from having tests for everything (being just a hobby...*cough*) I try to use what I'd call "ordered testing". The drawback is that it stops on the first failed test, but all functions used by that test should have already been through their own tests at that point, so the failure must be in the failed test itself. And later tests can safely use all previously tested functions if nessecary. (Though most functions are simple enough to not have any dependencies in the first place). TL;DR: The dependencies aren't explicitly written down anywhere, they're just implicit in the order that tests are run.

[Muche]

The dependencies aren't explicitly written down anywhere, they're just implicit in the order that tests are run.

I've read that an advantage of randomized test order is it could reveal hidden inter-test dependencies (e.g. a later test doesn't set the test environment properly and "relies" on an earlier test to do it).

[eradicator]

The dependencies aren't explicitly written down anywhere, they're just implicit in the order that tests are run.

I've read that an advantage of randomized test order is it could reveal hidden inter-test dependencies (e.g. a later test doesn't set the test environment properly and "relies" on an earlier test to do it).

Well, i guess you could split it into blocks? Ones that depend on each other and are tested in order, and the ones that don't depend and are tested shuffled? My amateurish self-made test environment doesn't really support randomization :D.

[Premu]

Wube's handling of quality is definitly outside of the norm compared to other game developers. I always was amazed what kind of bugs were solved which 99.9% of the players will not even notice. But this helps to keep out follow up bugs. I wonder about Kovarex's background: This seems to be quite untypically for someone who "grew up" in the game industry where holding timelines and having half baked features in is seemingly more important than delays or reduced releases. This philosophy is more at home in industries in which bugs can be really expensive.

At work (for an automotive supplier) we also use TDD. We even have a gate keeper in place to allow merges to the main develop line only if none of our automatic tests fail and no additional QAC issues pop up. Trying to keep together a highly complex and interwoven system without automatic testing routines is simply not feasible. It was pretty hard to introduce in a sensible way for us as we set up on a software which gradually grow over the years. So if you actually have the chance to introduce such measures quite early in the life cycle it's absolutely worth it, as it will keep the SW maintainable.

[BlueTemplar]

Yeah, it certainly seems to be paying off, now that both Wube and Factorio are big, and 0.01% of the players having a bug means ~30k people !

[bormand]

We even have a gate keeper in place to allow merges to the main develop line only if none of our automatic tests fail and no additional QAC issues pop up.

Yeah, commit gating is vital for large teams. It's not fun to work with a code when it's constantly broken here and there. And it's simply impossible to manually check all those little things every time, so bugs slip into the main branch causing havoc and delays for other devs.

But their team is quite small and skilful, so they probably don't need overhead of the gating yet... Tests, CI builds and notifications are still must have, though.

[NotRexButCaesar]

Is the link to FFF-288 under the gui tests section broken for anyone else?

[bormand]

Is the link to FFF-288 under the gui tests section broken for anyone else?

Yep, markup is broken there. Looks like quote after the link to the FFF-62 is missing.

[NoriSilverrage]

I'm not a real programmer (I've dabbled a bit) but I always enjoy reading posts like this because it's clear the developers care about the quality of their work. Without this drive I don't think we'd be able to build megabases because performance would be crap. This has to be one of the only modern games where performance is so highly desired and delivered upon.

Bravo team and thank you for your hard work and dedication! Factorio very well may be my most played game ever (especially if you consider all the Factorio dreams and musings).

Edit - Also, good lord, I didn't realize how toxic even formerly sane subreddits have gotten.

[fbo]

TDD is great if your management support it and sets timelines accordingly.
While programming is about computers, management is about people. And you need more disciplined programmers, because TDD is tedious:
- you're in fact doing double the work in one go (code & test) instead of the usual phases
- Instead of "yay, I did it right", after a while it feels more like "well, i did it - Again"

That's why you need to find a solution to break the workload down and also give people a feeling of success. Maybe intermix 'productive' phases using TDD and 'explorative' phases to try things out. The resulting mockups could be used as blueprints for later test cases.

[fbo]

I wonder: has anyone combined pair programming and TDD yet?

[Rachomejtl]

Ok. If I understand your long story correctly.. Your uncle Bob is author of factorio amazing Bob's mods ? I wonder what his mods would look like if he grew hornets. Probably more nuclear weapons ?

[bormand]

you're in fact doing double the work in one go (code & test) instead of the usual phases

One day I though the same... But then I noticed that I spend a lot of time just to check that my code works. Manually.

Also, I noticed that writing the test first forces me to think about the problem itself instead of the implementation details. So, when I start to write implementation, I already know most pitfalls and corner cases that I should handle. So, less time is wasted on bug fixing and refactoring.

And it's nice to see those green indicators when test passes

Maybe intermix 'productive' phases using TDD and 'explorative' phases to try things out. The resulting mockups could be used as blueprints for later test cases.

Yeah, it works too! Make quick and dirty prototype, then think over and stabilize it part by part (by class, by function, etc), covering them with tests and rewriting them to the production quality.