JEG2
How Best to Use TDD for Random Generation
There is some code that I’m still not good at building out with a process of Test-driven Development. One of those challenges is random content generators.
For example, I used to play a great BBS game called TradeWars. A lot of what made it fun was the way it generated interesting maps. Here’s an image of one:
Some neat features of what has been generated are:
- The dense cluster of interconnected sectors 1-7
- Rings like 52, 66, 76, 77, 67, and 53
- Choke points like 153
I might choose to force some features into every map, like the dense center. Then it makes sense to test for them. But what about things like chokepoints and rings? It’s possible that they wouldn’t randomly form. I guess I could randomly generate maps up to some selected cutoff, until I either find one or give up, but that feels like a super annoying Selenium test that just times out sometimes due to dumb luck.
I could lock a random seed, but that feels like it’s not exercising the generator very much. What if there are some random events that cause it not to reach the configured number of desired sectors? I wouldn’t find bugs like that I only ever checked known good inputs.
My instincts are to build a visualizer and just look at what it spits out until I have what I like. However, I’m really interested in challenging myself to see if I could use TDD to construct the code without this cheat.
Any thoughts are appreciated. Thanks in advance!
Trending in Questions
Other Trending Topics
Latest on Elixir Forum
Sponsor Spotlight
Catch errors, track performance, monitor hosts and more.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #performance
- #security
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Most Liked
stefanchrobot
Not an expert, but I think this might get easier if you switch from “a map has a 1/N chance of having X” to “at least 1 map out of N will have X”. So you’d generate a sequence of expected predicates (1 * “has X” + (N - 1) * “does not have X”) and then do a random shuffle. You’d need some state to keep track of when you need to generate a new sequence.
Last Post!
JEG2
I found this paper which recommends a three pronged approach:
2 and 3 are pretty clever. I like how they lean into the randomness and just try to cover a bigger portion of possibilities with the tests.
1 is basically the exercise left to the implementor. I do like the idea of writing tests for all the things I know to be true. It doesn’t allow for things that might be present, of course. Maybe there’s a lesson there though. If you really want something in there, the algorithm should probably enforce it.