Open ffigiel opened 8 years ago
@megapctr hi there!
Writing extensive integration tests
?Thanks.
1) the problem lies within discipline. Every developer has to pass every object they receive through your proxy. If they forget, some parts of application will still use plain objects, and the problem with undefined returns. Besides, it's not very convenient to pass every object through some function before you can use it. It also decreases readability and maintainability of the code.
2) writing tests means writing a program that will use your application and check if all results are valid. For example, a calculator
function given a sequence '2+2='
should return 4
. Following this example, an integration test would test something that uses the calculator function in some way, e.g. through an user interface with a text input.
My point about testing is that it's impossible to test your application in every possible way, because that is too expensive compared to other solutions (e.g. Flow). That doesn't mean you shouldn't write any tests (you should).
3) I didn't use flow and ts much, but the point is that your function can expect an object with a specific shape. For example, it may expect a user object that has a number field 'age' and a string field 'name'.
For examples on flow, you can check their documentation on objects
With proxies you can throw errors in case of a missing property, but that solution raises another problem: you can't really use plain objects anymore. You'd want all objects to raise missing property exceptions. If some objects are plain and some are behind your proxy, you will lose control over your code, not remembering which object is safe and which is not.
To handle current behavior with missing properties, you can do three things: