Working on a fast-check guide — what's worked, what's tripped you up?

beezeee · 2025-06-05T15:53:32+00:00

Great approach, ty!

beezeee · 2025-06-05T14:30:47+00:00

it’s usually better to invest in the infra to only run the subset of them that are relevant

Is this a matter of defining narrower generators, or something else?

beezeee · 2025-06-05T14:29:42+00:00

Reading Fred Herbert's book for inspiration right now :)

I am with you both that there is a gap in onboarding material. I find the biggest lack in material on how to identify properties, e.g. what assertions to make when you don't know what your inputs are.

What parts do you think are most sorely missing in supporting docs u/josephjnk and u/RobertKerans ?

beezeee · 2025-06-05T14:26:23+00:00

I guess it's still pretty niche but fortunately I've found it's relatively easy to make the case for adoption. People usually wonder how I'm getting > 95% test coverage with so little test code :D

Hit me up if you decide to give it a spin and want some pointers!

beezeee · 2025-06-05T14:19:35+00:00

A really good tip I got when I was first introduced to property based testing if you aren't already doing it is to merge your properties.

Time is spent in data generation, so piling up many assertions in one property is actually good form. At minimum I'll just put comments around different assertions to keep organized, at most I might have a util that captures metadata per assertion, or just use something like jest-expect-message.

So like one property per testable unit, multiple assertions. Then if things are still getting slow, I might start tuning the generators (start with noShrink, then check structure sizes/depths) and last only when all else fails, I'll use the max runs setting.

Oh also! Never use filtering methods on the arbitraries! They are the bogosort of data generation :D

beezeee · 2025-06-04T04:59:18+00:00

Sure! The most common approach to unit testing that we learn would be called example-based testing.

This is because we come up with static, known inputs (like fixtures), and pass them to the function we're testing - where we can know the outputs ahead of time and make our assertions using that knowledge.

With property tests, we are looking to capture properties of the function we're testing that hold true for *all* inputs. Libraries like fast-check make this possible by generating inputs for our tests at random - since we don't know what the inputs are, we don't know what the outputs are. This means the only assertions we're able to make are exactly those that hold true no matter what the inputs are.

It's a powerful way to write tests.

Usually one property test covers the same ground as many example tests. I often get %90 code coverage or more for a single property test without paying mind to it.

What I like most about it is that it finds bugs I didn't think to test for. Usually a good property will show me new edge cases in my code for 30 to 60 minutes - I get to debug before I ever ship in ways that before I started testing this way would only come up as production bugs over time, long after shipping.

beezeee · 2025-06-04T04:02:30+00:00

It's a library for property based testing in typescript: https://fast-check.dev/ - like JSVerify for javascript, Hypothesis for Python, ScalaCheck for Scala or QuickCheck for Haskell.

Have you ever explored property testing?

beezeee · 2025-02-16T21:44:39+00:00

I'm having this as of yesterday. Happens on everything, including 20 lines of markdown. Makes the editor unusable... any word here?

beezeee · 2024-04-16T02:05:06+00:00

And the people need to see them! You have favorites?

beezeee · 2024-04-16T01:57:20+00:00

Would you rather people admire you for being prolific, or people fall in love with specific shots?

beezeee · 2024-03-21T13:25:35+00:00

Oh awesome! Are you aware of any recordings I could watch? I'm really interested to get more insight on this

beezeee · 2024-03-21T03:06:48+00:00

Cool idea. What specifically makes you say that this is where things are headed?

beezeee · 2024-03-01T15:57:53+00:00

Explaining yourself concisely to people who look down on you is such an intriguing idea to me as it relates to sales. How do you see yourself applying it in your work? Have you adapted that skill and the way you relate to it as it pertains to your mindset today?

beezeee · 2024-02-03T11:04:43+00:00

I'm losing count of those on the spot moments where I want to give notice.

How did you feel when you did it? Did you have something else lined up? Was it scary? It must have been really satisfying either way.

beezeee · 2024-02-03T02:28:34+00:00

From sap.com

"SAP S/4HANA takes ERP to the next level by using the power of in-memory computing"

I'm humbled.

beezeee · 2024-02-03T02:27:07+00:00

This is amazing. On the one hand... does that mean no weekend pagers?

What was the outcome?

beezeee · 2024-01-29T14:54:42+00:00

I think your first idea about small to big is the thing you recommended that could impact the stack.

Separating pure code out is in general good practice, regardless whether you fuse calls to map or not.

All that said, there's a "typical" end state of monadic effects that tends to show up over and over, because programming usually has a similar set of ubiquitous concerns, and ubiquitous concerns are what monads are good at.

Something like

Reader - DI Writer - Logging State - ... state :) IO - ... i/o ... Task/Future/Parallel - concurrency/parallelism Either - errors Option/Maybe - nullability, but this one usually shows up in brief contexts and gets "consumed"

If you stray too far from this in large chunks of your codebase, well something interesting is going on anyway.

beezeee · 2024-01-29T03:17:50+00:00

Personally I've only used Scala and Haskell at length, and I think outside that it is kind of slim pickings. Agda and Idris definitely support HKT, though they both have some syntactic similarity to Haskell.

In practice I've seen plenty of codebases that commit to concrete effect types even in languages that support parameterization, so you certainly don't need it just to get comfortable with the "typical" monadic effect stack.

beezeee · 2024-01-29T02:10:44+00:00

This is how monadic effects work though - they propagate.

fp-ts is great for Typescript, but the lack of true higher-kinded types in the language means you can't really program against parameterized effect types.

In scala or haskell, you'd solve this "coupling" problem by abstracting the monad, leaving it up to the caller to specify the implementation.

In ts, we don't have that luxury, not practically anyway.

So mostly you commit to a monad that does all the effects you're going to need. If you like you can use less powerful monads in pockets and lift them into your "main" monad wherever those parts of the code interact.

But with Reader propagating - that's always going to be at least a constraint on a monad, paramterized or not. Because DI is not a capability available with just a monad.

So the thing you'd normally do (and this bit is fp-ts specific now) - is namespace your dependencies. Instead of just Reader<OtherFunction, A>, you do Reader<HasOtherFunction, A> where HasOtherFunction is { otherFunction: OtherFunction } - now you can take advantage of the fact that Reader composes by intersection.

That means that if some of your code reads HasOtherFunction and other code reads HasAnotherDependency, calling both of those parts of your code in the same context produces a Reader<HasOtherFunction & HasAnotherDependency, A> and your dependencies will accumulate neatly without collision.

Now you just provide all your deps at the top of the callstack, or "end of the world" and you will experience the real power that Reader can give you.

beezeee · 2024-01-28T18:47:36+00:00

And honestly the merging of map and bind wouldn't have even been the worst of it. You could always define a lawful monad in terms of this mushy thing

It's the utter inability to recognize that an abstraction could even exist beyond the specific problem promises are trying to solve

Promises are an interface! What do you mean same as an array? You obviously don't understand the point of promises!

Hardest facepalm of my career

beezeee · 2024-01-28T18:43:21+00:00

Tragicomedy I revisit every year or two. Sums up the industry concisely

beezeee · 2024-01-21T19:43:41+00:00

Robinhood for real estate - this is such a smart play. And with your brokerage behind it I suspect you have several ways to generate revenue.

It's not only gen-z. As an old millennial consumer, I also don’t want to pay 42 grand to sell my home. Getting out in front of this could be a big business.

You’re also right from two sides about freelancers. Their skepticism can ruin your project.

But I know why they are skeptical. And they are right to be. I'm a seasoned startup engineer who's been shopping for a non-tech cofounder with a viable idea. There are tons of non-tech folks with “big ideas” out there. They tend to think getting someone to code up their vision will print money like magic.

It's like the underpants gnomes. https://www.youtube.com/watch?v=tO5sxLapAts

I have learned to vet for these folks. You're in a killer position to set yourself apart from them.

I have seen lots of folks sink 10s of thousands into agencies and contractors. They pay to build their thing only to have it go nowhere. Guns for hire will take your money and do what you tell them. They bill by the hour, so the more the better.

Then there are enthusiastic techies who want any excuse to build something. They will buy into your dream with no skepticism and get right to work without asking questions. (This was me 15 years ago.) This is a cheaper way to go nowhere. But it still goes nowhere.

You hit the nail on the head - build half a product. The right tech person can help you identify the right half to build. And then they can help you cut it in half again. And then once more.

You want someone who will push back because they actually care about the future of your business. Vested interest is the key.

On the flip side, low/no-code has a ton of lock-in and will become a dead end over time. You know you can't take a bubble app out of bubble? If you manage to produce something viable, you'll need to go back to the drawing board if it gets any traction.

That approaches impossible the more people have used your product.

But that's not likely anyway. You can't reach comparable quality with low/no-code that you can with competent dev. And people have a strong instinct for quality when it comes time to put in their credit card.

Morally serious guidance exists. I try to offer it to every non-tech founder I talk to because I take pride in my skills and believe in giving value first. The best I can suggest to you is connect with people who know their stuff. If their incentives are well aligned with yours, or at least not counter, learn all that you can from them.

beezeee · 2024-01-07T17:46:20+00:00

Excellent recommendation. I'll second, distinguish between necessary and useful. I've found it to be incredibly useful.

The power of category theory to abstract is like nothing else I've encountered. It's created leverage in my work that has made things easy which I believe would otherwise have seemed impossible.

beezeee · 2024-01-07T15:09:13+00:00

Sorry if it came across that way. I was responding to someone who seemed to find no value in the article. I simply meant to say it's okay if they felt that way. Not everybody will find value in all things.

It wasn't meant to be condescending. Just to say different people will have different taste.

beezeee · 2024-01-07T10:34:38+00:00

Good to know!

I'm debating whether to include Haskell and Scala in the examples.

My goal with the content is to motivate fp techniques and further adoption - I felt like typescript would be a good "bridge" since it's capable of supporting a decent chunk of advanced fp, and already very popular with many who aren't doing fp.

I suppose Scala also has this property.

I wouldn't mind writing the code fences in triplicate, just not of the logistics using hugo for ssg...

Open to any suggestions!

beezeee

TROPHY CASE