thank you! fixed

Great kata! The only minor issue I encountered was mis-casing of dateOfbirth property (proper camelCase would be dateOfBirth).

(I'd keep arguing but I don't think I would be adding any value. I don't think you're providing any reason for why this static function should be wrapped in a class)

yes, I've removed all rounding hacks and all tests are passing now

rounding issue seems fixed

You sometimes expect empty natural resources rather than an empty list (note that expected and actual are switched)

expected: {"time":0,"raw":{"copper-ore":0,"iron-ore":0}} to deeply equal {"time":0,"raw":{}}

actual and expected and switched in random tests

It should be fixed! Please, test it and let me know.

No, no rounding, please, you just use approximite equality instead

I'm seeing this too in the expected time:

expected { time: 8.7, raw: { 'heavy-oil': 87 } } to deeply equal { time: 8.700000000000001, raw: { 'heavy-oil': 87 } }

The solution to this kata serves as a singletone service! Passing a constant collection as a parameter each time is not advisable, as CW users will be working with it throughout the kata. The code written in the 'Initial Solution' shows that when creating an instance of the class, the class will receive a collection of recipes. You can also see this in the "Example Test Cases."

Having read your non-spoilered responses I am still not seeing how that adds value. As far as I can tell it is a convoluted inconsistent way of representing a parameter. And everyone that solves it is going to have to wonder what that code is doing there, followed by not using it in any way.

My random tests keep failing because of some strange rounding issues:

1. amounts in the raw object seem to be rounded to 1 decimal point - I could round the result in the same way, but it seems pointless and hacky
2. time value doesn't match the test by a 0.0000000000001 - and I can't event hack this diff to pass tests (most of the runs, it's the expected result that is not rounded)

I might guess it's because random tests can request a non-integer number of portions (amount % yield !== 0).
Or am I missing anything in the algorithm?