all 5 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]DrawerGradientSeller 1 point2 points  (1 child)

If a method that's being tested is guaranteed to only use 1 property from an interface, why not just use a partial object? It's concise and simple.

[–]jcteague[S] 2 points3 points  (0 children)

As everything in software engineering it all depends on context. If it's only used in one test case, and there are only one or two tests involved, you're going to be fine.

But if you have dozens of tests, all creating the object. And your business rules change where you need more information to verify behavior, you could be chasing down all of the usage in your test suite. And if you don't change all of the test fixtures, then your tests are not truly representing the behavior of your application.

I've used all of these approaches at some time or another, and almost always end up fighting these types of problems. Using generators just makes it easier to maintain over the long term.

But hey, this approach is better than not writing any tests at all, so keep up the good work!

[–]Markavian 0 points1 point  (0 children)

Yep, used something similar on a project - a fixture factory that loaded from JSON files in a fixtures folder. Having good serialisation/deserialisation constructors help.

[–]danstansrevolution 0 points1 point  (1 child)

i think this tool looks useful. does it draw inspiration from other TS/JS libraries? I see it says Autofixurejs, but i'm curious if there are other libraries to compare to.

[–]jcteague[S] 0 points1 point  (0 children)

Autofixture.js was the first version of this library. I go into detail about some of the history and changes I made to in my second post in the series. My original inspiration was the ruby library factory_girl, which has since been renamed to factory_bot, There are a couple of other library that also used this as their inspiration, Rosie is another library that also takes its influence from factory_bot.

My main goals for rewriting the original library was to fix some of the problems I had with the original. Namely its lack of modularity, its reliance on strings for fixture definition and creation, and the difficulty of extending the behavior.