Comments (3)
This is by design, provided overrides are merged recursively onto the created mock.
In general this is the standard way of doing it, let's look at your example:
const testMock = createMock<TestInterface>({testAttribute: test});
What does this mean? If you want the objects to be provided by reference it means that the whole { testAttribute: test }
will be assigned to the mock, hence making it the effective mock. This means that there is no need to use createMock and this is enough:
const testMock = { testAttribute: test };
There is a solution, that is to check if the object provided has the same properties than the mock object and provide by reference only if all the properties are provided... but this becomes very inefficient if we start working with big deep objects.
A quick example is an interface like this:
interface INode {
child?: INode;
name: string;
}
createMock<INode>({ name: 'root', child: { child: { child: { child: { name: 'a name' } } } } });
Is root here provided by reference? Why not? Checking that would make the code slower than it should be and we would probably get more issues like this one where someone else didn't want the object to be provided by reference.
If this is a common feature request I can think of a solution, in the meantime in the next part I'll explain two ways of achieving this without having to add any feature to ts-auto-mock
One way of achieving this is to follow the documentation that says that if the provided override is a mock then it's provided by reference, another is a simple solution that just adds one line of code to your example.
So what you can do is:
interface TestInterface {
testAttribute: {
id: number
};
}
const test = createMock<{ id: number }>({ id: 0 });
const testMock = createMock<TestInterface>({testAttribute: test});
test.id = 1;
const finalTest = testMock.testAttribute.id === test.id; // true
or without having to resort to hacks:
interface TestInterface {
testAttribute: {
id: number
};
}
const test = {
id: 0
};
const testMock = createMock<TestInterface>();
testMock.test = test;
test.id = 1;
const finalTest = testMock.testAttribute.id === test.id; // true
Hope this helps :D
from ts-auto-mock.
Checking that would make the code slower than it should be
Yes, features do make code slower. The question is, does this decrease in performance actually make a difference?
(...) we would probably get more issues like this one where someone else didn't want the object to be provided by reference.
As Typescript objects get assigned by reference per default, I feel like the current behaviour where objects get copied - given they are not mocks themselves - is rather counter-intuitive more so than intuitive.
from ts-auto-mock.
Just an idea here: Is it possible to check if attribute values of the passed object are variables rather than literals?
Oh well now that I think about it, if the attributes are given by a literal or a variable doesn't really determine if it's partial or not, because you can also put the partial assignment into a variable first, before calling createMock
.
What you could maybe do is checking the prototype chain of objects. If they are instances of the respective type you could reference them instead of copying, but this would only work with classes.
from ts-auto-mock.
Related Issues (20)
- Error on ESM TypeScript project when using ts-node + mocha HOT 1
- Is there a minimum node version requirement for `ts-auto-mock`? HOT 5
- does it support @swc/jest? HOT 1
- ts-auto-mock with isolatedModule in jest config not working
- does it support Vitest ? HOT 1
- Passing a generic type to createMock throws weird error in a wrong place! HOT 3
- Change Automock Default-Values HOT 1
- "ts-auto-mock" is not published error HOT 2
- [Doc improvement] Improve the `ts-jest` configuration in the docs HOT 3
- typescript 4.9.3 deprecation warnings HOT 1
- The requested module 'ts-auto-mock' does not provide an export named 'createMock' HOT 1
- Support Typescript 5 HOT 10
- Type errors with nested mocks after Typescript 5 upgrade HOT 9
- createHydratedMock() should return Required<T> HOT 1
- Overriding functions does not work HOT 2
- Typescript 5.2.2 : TypeError: DeprecationError: 'originalKeywordKind' has been deprecated since v5.0.0 and can no longer be used. HOT 3
- instanceof doesn't seem to work with class mocks
- Forwarding generic leads to ReferenceError HOT 6
- Error in install instructions on Github Pages website HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ts-auto-mock.