June 16, 2022

Game Development in Rust

Hey I wrote a book! You should buy it! It's been out for two months, so it's probably time to actually blog about it. In the spirit of Scott Hanselman saying I have a "finite number of keystrokes" I'm going to base this on the twitter thread I already wrote, specifically on how the book came to be. Game Development has been a semi-professional hobby of mine for m entire career.

December 13, 2020

Mock Objects (manually) in Rust

As I've been learning the Rust programming language and the Godot game engine (streaming at http://www.twitch.tv/paytonrules) I've been increasing the amount of testing I've been doing. I started by doing..well none.. and have been moving more and more into a TDD flow as I become more comfortable with the language and environment. One of the real challenges with TDD in Rust was figuring out how to use mock objects or substitutes.

November 1, 2020

Immutable Code with mut self

Recently I started streaming my adventures with godot-rust over at https://www.twitch.tv/paytonrules. Come visit, while I'm still small enough to let you backseat code. The first completed project is a Blackjack game, where the code is entirely written in Rust using the Godot game engine. I wrote the code bottom-ish up, where I test-drove a command-line version of the app first, and then attached a mostly test-free Godot UI on top.

August 23, 2020

Porting Godot Games To Rust (Part 1)

NOTE This guide has become obsolete. Unfortunately (for me) godot-rust came out with version 0.9-preview shortly after I wrote this blog, and large chunks of this blog are just plain..wrong. You can see 0.9 compatible code here: https://github.com/paytonrules/AirCombat - as I updated the code itself. Unfortunately though the tutorial before has quite a few obsolete ways of doing things, including all the unsafe code. Of course if you're using 0.

April 7, 2020

Teaching ReactiveX (and a lot of other things) Like Skiing

This blog originally appeared on 8th Light’s blog I’ve been intrigued by ReactiveX, in all of its programming-language variations, for a few years now. I’d see code like this: const bricks$ = generate(1, x => x < 8, x => x + 1) .pipe( mergeMap(r => generate(r % 2 === 0 ? 1 : 0, x => x < gameSize, x => x + 2) .pipe(map(c => createGameObject(r, c))) ), toArray() ) Source: Breakout Game

September 2, 2016

Testing Private Methods - Yet Again

I guess it’s that time of year again - time to write about testing private methods. It’s a constant question because it sounds like a game changer. The logic goes something like: TDD tests public methods. Most of my code is in private methods. Can’t do TDD. Baby - meet bathwater. My last blog gave a very specific solution to this problem. This time I’m going to try a more general approach.

July 27, 2016

Testing Procedural Code

This answer was originally posted on the Programmers Stack Exchange. I’ve reproduced it here, but more generically as I don’t have the permission of the original questioner. As such I’ve changed the code to be unspecific. If you want to see the original, it’s here. When it comes to TDD some of the simplest code can be the hardest to test. Let’s peek at an example: public void CopyCustomers() { var sourceCustomers = _sourceRepository.

June 27, 2016

Testing Untestable Code

When it comes to TDD one of the problems is hard to test or “untestable” code. New and even intermediate practitioners often struggle because standard exercises like “Bowling Game” don’t reflect a real world environment. So when they struggle with databases, UIs, crummy code and other they start to wonder if TDD can really work for them. How do you write more testable code? Do TDD! How do you make TDD easier?

April 18, 2016

Please Don't Use Fixtures

Fixtures are a really attractive feature, particularly for developers that have been doing TDD for a little while and are starting to see ugly tests. The first tests you write using fixtures will be simpler and easy to read but over time they make tests slow, confusing and brittle. They are a bad idea. What’s a fixture? Since this is software there are naturally several definitions but what I’m referring is any testing tool that allows you to setup test data in a seperate file than the tests themselves.

February 19, 2016

You're getting SRP Wrong

The Single Responsibility Principle, or SRP states that a every module or class in a system should have “one reason to change”. Unfortunately that often gets misread as “do only one thing” and that can lead to massive problems in your design. Let’s take a look at an example: var Router = function(dtoFactory, serializerFactory) { this.createUser = function(params) { var dto = dtoFactory(); dto.userName = params.userName; dto.

December 5, 2015

UI hard? Write it last.

TDD on a UI can be extremely difficult. UI’s change constantly, they’ve got strange interfaces that aren’t easily mocked, and most importantly tests don’t provide they kind of fast feedback they do on back-end code. Specifically you don’t really know if you got a UI right until you see it. That leads to a workflow where you write the code to see the change in the UI, then write a test for it.

November 6, 2015

The Mock Broke Again

You’ve written your big cool feature. You’ve written every single line with TDD, and of course the tests pass. You tried out the feature locally, and it worked there too. Then you deploy it to production - and it breaks immediately. Humiliated you start debugging the problem and you see something like this (in ES6 flavored JavaScript): it("saves a user to the database", () => { let database = new FakeDatabase(); let user = new User(database); user.