-
Notifications
You must be signed in to change notification settings - Fork 126
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
No test - no run #34
Comments
Assuming that the language would be compiled, this could be a part of a build script, which would compile a program, run the tests afterwards and fail the build in case something goes wrong. I think, green tests should be a requirement for the shipping, not for the compilation. Otherwise, a language lacks a lot of agility. |
Maybe it should raise a warning, not an error. |
How the compiler will know that a program is a tester and other is the real program? |
@mdbs99 We don't have tester program. Compiler is a tester. Eg, if method accept an integer, we must to test his behavior with positive, negative number, with zero, max_int and min_int. If we don't wrote test for zero, we can't be sure in our program. But if argument can't be a zero, it's not an integer. |
@MadridianFox I can't understand how this will work. |
I think what I gone too far with testing of all cases. It's may be impossible to find all use cases of object by arguments. |
It seems very opinionated for the language/compiler to require unit tests. (I could also imagine people getting into the habit of writing a bunch of probably pointless tests just to keep the compiler happy.) Encouraging and facilitating unit testing is a different thing altogether of course. I guess I'll be interested to hear what Yegor thinks. He's not one to shy away from being opinionated (which is all good in my book). But at the moment I think this is a step too far. |
@pa9ey Yes, newbie can make empty tests for compiler satisfaction, but serious developer knows, that code without test is dead. It's not maintainable. |
How compiler understand for test needed? Run tests in compile and require test succes is good idea. Question in other. :) |
@DronMDF What is test? It is a specification of object's behavior. In some cases, we need not only describing of inputs and output of method. We need some computation for prove accordance object to spec. |
I'm ok with those who say that only the complex behaviors need unit tests. The other object's behaviors, if written in a concise and strongly typed way, doesn't need tests. The compiler must launch the already written tests, but i think that it must not require from the devs a 100% code coverage. |
@MadridianFox I like the idea, a lot. I actually mentioned in the original prototype the necessity for the language/platform to support TDD. Not unit testing, but TDD. @pa9ey is right that just requiring tests to exist is not a good idea, because will lead to a lot of placeholders with no real meaning. We need to find a way to encourage coders to use TDD: tests go first, implementation next. Ideas? |
@yegor256 Unfortunately, we can't to forbid have code without test. There are "old" java libraries and some code with side effects. We need to have an mark for non-testable code, but it give to user way to violate testing policy. It irresistibly. |
@MadridianFox what if allow people to share objects only through objectionary (#22) and will accept there only objects with certain level of test coverage? |
@yegor256 Terrible thought! Monopolistic repository tying the hands. It may be repository by default, but people should be able to work in closed web or even without it. |
Quick thought - objects, which satisfy tests just like they implement types. Methods, accepting objects, which satisfy specific tests. Which implies global tests associated with types, not with objects. In order to inspire people to use TDD, one shouldn't be restrictive. One should smooth the way to it and make TDD easy and pleasurable to use. Assuming that every object declaration(= type implementation) would be global, I'd like to see tests right there, after the methods and attributes. Also an environment which could run the tests out of the box. Then everything a developer should do is to write a test. Not to configure anything, not even to create a separate file. |
Think Intention Driven Design or Documentation Driven Design. One thing I hate about the modern English language is how much it has given way to bloat. For instance, using the word "conflate" has become trendy, when it holds no special attribution over "merge". That's ambiguity, and thus bloat. Who cares if you have a strong vocabulary, if all the words you know mean the same thing. Does it really aid your articulation? My point! Well, just as the purity of a spoken language should be preserved, so should an object domain where every object has a unique purpose. If every object has a unique purpose, it should only exist as a child part of a composite object, or a front-end object that addresses a user requirement. Every requirement should be documented. So if we standardize requirement documents, such that they live with the code and contain hooks to real objects. You should end up with %100 code coverage, because the intention of every object in the application must be described somewhere. This doesn't even have to be as clunky as tools like JBehave, Cucumber, etc. But a compiler could start with a Latex or Markdown document and test the objects, with examples, cited within them. And then test any Type level EO docs if available as it traverses down the object tree. (As I've come to believe that if anything, JavaDocs of classes should contain examples of how to use the class, rather than how the class does it's job) This way you naturally force documentation and code coverage. The code should never describe more than the documentation and vice versa. |
Class level JavaDocs should have unit tests in them! This occurred to me as I was blabbering in my previous post. Unit tests described in a Class JavaDoc would require a dependence on a fake object. Yet fake objects should be apart of the source folder, and tagged for the build manager to ignore. So I don't really see a problem with the dependence. Also Yegor and I may disagree on this. But some mocking capability would be advantageous in such a case. Example:
|
@Tertioptus isn't this what you're talking about? |
@gukoff Yes, thank you! programming by contract. I think EO could do it even better. Plus your IDE could automatically run the test while the Class/Type is being written. Such that when the objects behavior is fully implemented, the test lines go from red to green. Kind of a dynamic TDD. Which would be very satisfying, and reward both documentation and testing efforts immediately. |
Maybe a documentation tests concept from Rust can be helpful: |
@MadridianFox it was a good idea, but I decide to close it. We will have a traditional model: code+tests. The validation of test coverage will be done outside of language scope. |
Job |
How about, mandatory testing? Objects have methods and every method must be tested. If at least one method has no test, compiler have a right throw a warning or even cancel compilation.
Good test - that test which cover all possible cases. We can extract these cases from expected exceptions of inner objects and from special cases of method's arguments.
Exceptions - the old song of OOP programming. But formal sign of special case for type - is something new.
What you think about this?
The text was updated successfully, but these errors were encountered: