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

Regular reports on Factorio development.
User avatar
FactorioBot
Factorio Staff
Factorio Staff
Posts: 340
Joined: Tue May 12, 2015 1:48 pm

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

Post by FactorioBot »


User avatar
BlacKcuD
Burner Inserter
Burner Inserter
Posts: 8
Joined: Sat Mar 05, 2016 3:50 am
Contact:

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

Post by 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!
Angelbobs Megabases for life!

User avatar
BlueTemplar
Smart Inserter
Smart Inserter
Posts: 2206
Joined: Fri Jun 08, 2018 2:16 pm
Contact:

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

Post by 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
Factorio Staff
Factorio Staff
Posts: 8053
Joined: Wed Feb 06, 2013 12:00 am
Contact:

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

Post by kovarex »

BlueTemplar wrote:
Fri Jun 18, 2021 10:56 am
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 ... :)

User avatar
BlueTemplar
Smart Inserter
Smart Inserter
Posts: 2206
Joined: Fri Jun 08, 2018 2:16 pm
Contact:

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

Post by BlueTemplar »

Maybe for 2.0 ? ;)

EDIT : Also, no automated spellchecking, "swithing" :P
(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
Long Handed Inserter
Long Handed Inserter
Posts: 73
Joined: Tue Feb 03, 2015 10:58 pm
Contact:

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

Post by AnarCon »

ah.... 0.6 i remember thee foundly :D

Amarula
Filter Inserter
Filter Inserter
Posts: 390
Joined: Fri Apr 27, 2018 1:29 pm
Contact:

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

Post by Amarula »

kovarex wrote: 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.
Luck is not a robust control.

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5201
Joined: Tue Jul 12, 2016 9:03 am
Contact:

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

Post by eradicator »

kovarex wrote: 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.
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

Muche
Long Handed Inserter
Long Handed Inserter
Posts: 51
Joined: Fri Jun 02, 2017 6:20 pm
Contact:

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

Post by Muche »

eradicator wrote:
Fri Jun 18, 2021 2:16 pm
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).

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5201
Joined: Tue Jul 12, 2016 9:03 am
Contact:

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

Post by eradicator »

Muche wrote:
Fri Jun 18, 2021 3:03 pm
eradicator wrote:
Fri Jun 18, 2021 2:16 pm
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.
Author of: Belt Planner, Hand Crank Generator, Screenshot Maker, /sudo and more.
Mod support languages: 日本語, Deutsch, English
My code in the post above is dedicated to the public domain under CC0.

Premu
Long Handed Inserter
Long Handed Inserter
Posts: 79
Joined: Wed Nov 13, 2019 4:40 pm
Contact:

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

Post by 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.

User avatar
BlueTemplar
Smart Inserter
Smart Inserter
Posts: 2206
Joined: Fri Jun 08, 2018 2:16 pm
Contact:

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

Post by 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 !

User avatar
bormand
Fast Inserter
Fast Inserter
Posts: 200
Joined: Fri Jun 05, 2020 9:59 am
Contact:

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

Post by bormand »

Premu wrote:
Fri Jun 18, 2021 5:45 pm
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.
Last edited by bormand on Fri Jun 18, 2021 6:54 pm, edited 1 time in total.

User avatar
NotRexButCaesar
Smart Inserter
Smart Inserter
Posts: 1046
Joined: Sun Feb 16, 2020 12:47 am
Contact:

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

Post by NotRexButCaesar »

Is the link to FFF-288 under the gui tests section broken for anyone else?
: Alea jacta est. Determine what you intend to accomplish with an action before execution.
Have you ever heard the gospel? Most have not.

User avatar
bormand
Fast Inserter
Fast Inserter
Posts: 200
Joined: Fri Jun 05, 2020 9:59 am
Contact:

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

Post by bormand »

NotRexButCaesar wrote:
Fri Jun 18, 2021 6:53 pm
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
Fast Inserter
Fast Inserter
Posts: 158
Joined: Mon Mar 21, 2016 1:19 pm
Contact:

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

Post by 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.
Last edited by NoriSilverrage on Fri Jun 18, 2021 7:07 pm, edited 1 time in total.

fbo
Burner Inserter
Burner Inserter
Posts: 9
Joined: Sat Dec 30, 2017 4:48 pm

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

Post by 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
Burner Inserter
Burner Inserter
Posts: 9
Joined: Sat Dec 30, 2017 4:48 pm

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

Post by fbo »

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

Rachomejtl
Manual Inserter
Manual Inserter
Posts: 1
Joined: Fri Jun 18, 2021 7:15 pm
Contact:

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

Post by 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 ?

User avatar
bormand
Fast Inserter
Fast Inserter
Posts: 200
Joined: Fri Jun 05, 2020 9:59 am
Contact:

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

Post by bormand »

fbo wrote:
Fri Jun 18, 2021 7:03 pm
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 :P
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.

Post Reply

Return to “News”