TDD in C using Prediction


Last weeks I've been working on some legacy code. Most of it has been refactoring, but we rewrote a couple of modules to we test-drove these... of course. The TDD cycle is so slow that it made me realize a technique I'm using... but wasn't aware of. I'll simply call it "predictions" :) It speeds up your TDD cycle a lot.

If you are developing multi-player games then you'll have to deal with the network latency. The graphics on your screen and the behavior of the players is faster than the packages on the network. That means... if you would draw a player only after you got its exact location over the network... then your gameplay might turn out to be crap. One technique that has been used for years is "prediction." The client will predict where the objects are located... then made adjustments based on the real packages coming in. Most of the predictions can be reasonable accurate and that will speed up your game and save your gameplay.

TDD in C often has a slow cycle. The test of the particular component I worked on last week ran in 7 seconds (down from 15 after some setup refactoring). However, the linking took perhaps also 5 seconds. A rebuild would take about 10 minutes. Having incremental compilation, most of the time we just edit a couple modules, so the compilation of that was perhaps 2-3 seconds. Thus... for an incremental change.. total cycle time about 20 seconds. For a header change (with includes being messed up as they were.. being legacy) about 10 minutes. Such a cycle will bore any TDD-er.

So, if you are in such an environment... you might want to use "prediction." The information about were we are will be delayed due to compiler latency. So to increase our gameplay, we'll predict were we are. We'll turn on the compiler, predict the tests to be red and start implementing it. The compilation/linking and test run will happen in the background. When they are finished, we received the information we needed to make our correction. Most of the time our predictions are pretty good. However, sometimes we start coding in the wrong direction and we'll need to undo our changes and get back to the reality... the tests. We'll predict about 1 minute in the future and that way make our TDD cycle fast and it saves the gameplay.

Test-driving with prediction makes TDD in C almost like TDD in Java (missing most of the automated refactoring, but the CDT ones help a bit).

Of course... we do need to be careful that the prediction doesn't move us away from TDD. We don't want to speculate too far in the future. We certainly don't want to implement functionality that we don't have a test for. We only want to predict the outcome of the compiling/linking cycle and the test run.

Read more

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai