11–20 of 100 posts
>finally, we can stop creating an interface for every class just to mock it in tests Is there more information available about this? Would be great to achieve this natively without requiring Fody and friends.
class Point {
public Point(this x, this y);
int x;
int y
}
And still patiently waiting for the following to be legal:
int result = some_variable switch { a => callAFunctionReturningVoid(); 1, b => 2, };>finally, we can stop creating an interface for every class just to mock it in tests Is there more information available about this? Would be great to achieve this natively without requiring Fody and friends.
I've HATED it when people do this, but everyone is convinced it's best practice.
You can create integration and e2e tests that aren't as sensitive but I don't really understand what people are suggesting when they say mocking is bad in unit tests.
Having other languages be the guinea pigs for language features is a good way to go.
Earlier quoted context omitted.
I've HATED it when people do this, but everyone is convinced it's best practice.
What is the alternative specifically for unit tests? You can create integration and e2e tests that aren't as sensitive but I don't really understand what people are suggesting when they say mocking is bad in unit tests.
"Unit test" does not necessarily mean "class test" or "method test"
and always treating it as such is counterproductive.
I have done it both ways. tests coupled to every public method with dozens of mocks would not be my preference.
Not sure if I like primary constructors. TBH, the following feature of Dart that I like: class Point { public Point(this x, this y); int x; int y } Everything else seems like small quality of life improvements. And still patiently waiting for the following to be legal: int result = some_variable switch { a => callAFunctionReturningVoid(); 1, b => 2, };
I love that Java and C# (not sure about VB.NET and F# in the .NET ecosystem) are continuing to get handy language features instead of collecting dust. The array syntax stuff is a nice win. Having other languages be the guinea pigs for language features is a good way to go.
Java has recently left the freezer and seems to be catching up as well. I don't use Java but I see people excited about new releases since v11 or so.
Earlier quoted context omitted.
I've HATED it when people do this, but everyone is convinced it's best practice.
What is the alternative specifically for unit tests? You can create integration and e2e tests that aren't as sensitive but I don't really understand what people are suggesting when they say mocking is bad in unit tests.
It is irrelevant and driven by some testing evangelists
Tests are either quick or slow and may touch external stuff, thats mostly it.
Whats wrong with mocks? If they lead to scenarios where your tests are green, but app doesnt work then it sucks. Ive witnessed projects with all green tests but app wasnt even waking.
Earlier quoted context omitted.
Some would argue that creating interface for every class and using too much mocks than actually needed is baad.
Yep. The issue with tests that are heavy on interfaces and mocks is that they are "too close" to the code - if refactoring is changing code while tests stay green, how can you refactor when any change to any method breaks a test? Swapping out interfaces to code-gened interceptors and keeping everything else the same, doesn't look like it would improve this underlying issue at all.
You fix until tests pass. How do you know you adjusted all tests when code changes and tests stay green?
Not sure if I like primary constructors. TBH, the following feature of Dart that I like: class Point { public Point(this x, this y); int x; int y } Everything else seems like small quality of life improvements. And still patiently waiting for the following to be legal: int result = some_variable switch { a => callAFunctionReturningVoid(); 1, b => 2, };
this parameters (well the first one) is already used for extension methods. Constructors can't be extension methods but it could still lead to confusion