Is the Dart philosophy compatible with testability and dependency injection?

Question

One of the Dart criticized features are named and factory constructors.

There are opinions (from dependency injection people), that constructors should be simple and just assign some fields and the object graph creation is a responsibility of factories.

There are also some argues against the static methods.

It seems, that Dart constructors bring complexity to constructors. You can not even have a lot of named constructors to create the object in a various ways, you can even have a static factory supposed to construct object of other type than the class it is in.

So, what is the philosophy of Dart and how does it relate (or respond) to the Dependency Injection and no-static state philosophies?

• David Sergey: According to article you linked, Functional code can't be tested, and that's untrue. Quote: "The basic issue with static methods is they are procedural code. I have no idea how to unit-test procedural code. Unit-testing assumes that I can instantiate a piece of my application in isolation. During the instantiation I wire the dependencies with mocks/friendlies which replace the real dependencies. With procedural programing there is nothing to "wire" since there are no objects, the code and data are separate."
• Robert Harvey: People think static methods are untestable because they do dumb things with them like manipulate static state. If you keep them immutable, static methods are the most testable of all.
• OZ_: @RobertHarvey people think static methods are untestable, because you can't use mocks with code, which use static methods.
• Robert Harvey: @OZ_: Purely functional code must not be testable at all, then.

Answer 1

Constructors are where you should construct things. That's why they are so named :)

The alternative to constructing everything in the constructor is that you will have a half-constructed object that you then rely on the rest of the program to handle well until its had its properties initialised. This makes things more complicated than they should be - compared to always having a fully constructed object. Martin Fowler talk about this.

I'm not sure about Dart's philosophy of constructing - if you can't overload the constructor for different cases, it sounds a bit limiting.

• OZ_: But if you instantiate new (other) objects in constructor, you can't test this code.
• gbjbaanb: @OZ_ but how do you test an object's created correctly without accessing its state and testing those accessor methods too? Don't let yourself be fooled by the tools that generate single method stubs for tests, a unit test can be more than just a method, as Fowler says. Testing a class as a unit allows you to create how-to-use documentation too, something that a single method test is often useless at.
• OZ_: it's funny how you've imagined that I use some tools and even ask me to not use them, when it's only your imagination :) All my tests are hand-written, don't let be fooled by your imagination.
• gbjbaanb: @OZ_ they you should have no problem testing a class and its dependants, so I don't see why you asked the original question.
• OZ_: It wasn't me :)