Would Mojo have automatic test generation

[hard turret]

Since Mojo is a superset of Python, it will have support for doctests (https://realpython.com/python-doctest/) which combine documentation and testing. It will also have support for unit tests for TDD.

As for contracts, C++ currently has them. Maybe Mojo can take inspiration. Personally I think it's better to combine asserts and contracts into one feature instead of having to learn two things that achieve similar things.

[vapid raft]

Maybe Mojo could take Inspiration from dependent type instead of contracts. Where you could specify the constraints directly inside the type and have compile time checking

[vapid raft]

Maybe for example like
fn concat(list1: List[A, n], list2: List[A, m]) -> List[A, n+m]
Where concat([1, 2, 3], [4, 5, 6]) -> [1, 2, 3, 4, 5, 6] ,
concat([1, 2] , []) -> [1, 2]:
return list1 + list2

So you have type safety when writing the test cases

[hard turret]

I'm not familiar with dependent types, but Mojo already has the "constrained" function for compile time checks

Would using it work?

[hard turret]

This doesn't look different from unit tests to me

[vapid raft]

With unit tests I have to do more Setup. Like mocking out dependencies

[vivid slate]

Congrats @vapid raft, you just advanced to level 3!

[vapid raft]

For example if you have a class you first how to Init all the dependcies

Have to*

Here maybe the compiler knows these are the dependencies and how to Init them to create the test

And when a dependency changes you have to adapt a lot of tests sometimes

[hard turret]

I don't know what that would look like. We'll see if the team considers this. They did say that the compiler deliberately wouldn't be "magic" so they could keep compile times low, and this seems like magic to me.

[vapid raft]

But you still have to execute tests when introducing change to a software, so the overall time should not be more. You can also maybe make it smarter and just compile the things which changed so not all tests are executed again for every change

Basically you just save time by not having to maintain and write boring code

[vapid raft]

And I think the above code is more beautiful because it is type safe compared to docs and you exactly see how some code is used instead of having to look up some test somewhere in a different file

I know there are approaches where some test are already automatically generated like with property based testing so if this feature is appealing to the mojo team maybe can also take some ideas from there for this approach

[hard turret]

Doctests already achieve this. If the code in the documentation is wrong, the test fails.

[vapid raft]

AFAIK doctest is not type safe and are not like contracts n+m for example like my example the return type List[A, n+m]. So my code above could unify like doctest functionality with constraints plus type safety

And solving the boring test setup problem

[vapid raft]

But as you said if this seems like magic maybe this would not work in the general case and you would still have to fallback to regular testing for more complex cases

Would Mojo support contracts or dependent types and compiler based automated testing

Or figuring out how to setup all these tests would increase compilation significantly compared hard coding it in a test

But at the same time if this increased compile time at the same time you won developer time so in the end you still more faster because developer does not have to spend time figuring out how to setup some test

Thanks for being devils advocate but @pliant drift and the mojo team might still not have the time or care about all this stuff 😂 I am out.

[vapid raft]

I have to force some people to write more tests. There is a lot boilerplate involved and when things change a lot of this boilerplate is broken and has to be adapted. With my approach doing this testing is more fun, because it reduces all this boilerplate and testing conceptually to give a counterexample to some algorithm, see the where clause. So when it is more fun and finding counterexamples is fun in my opinion, the probability increases that there will be more testing and therefore there would be less buggy or broken Mojo code, which would let Mojo appear better for writing safer, reliable software and therefore makes it more attractive for new people to adopt.

[vapid raft]

And this approach would also fit nicely with AI tooling like GitHub copilot. So give the special cases after where clause in TDD fashion and AI generates the code. When Code and test are spread in different files how should the ai generate it as nicely?

[pliant drift]

"Care" about things is complicated term to use - there are a ton of things that we care about and want to do, but don't have time for right now. A lot of "success" in large scale systems projects comes from "intense focus" 🙂

Right now, we're building out the foundation of Mojo, and there are a lot of (fairly obscure) technical foundations that need to be right before jumping to more elective things. We're focused on building that out, and the rough plan is in the roadmap doc

[vapid raft]

It is great that you and the rest of the team are so focused on the foundation of Mojo and that obviously has the highest priority. It would still be interesting to know, if my approach above would be technically feasible. I write a lot of test code and it would definitely help to make testing easier, save time and probably for other devs, too. When I do Software development, I decide first what to do and then how to do it, this is naturally done with the syntax in my code example above. In today programming, this is separated into two files, if you see testing as defining the expectations.
When thinking from first principles and also about the current state of for example AI tooling, this approach seems reasonable but there might of course be blindspots I am not aware of. By the way, thank you for replying. It is great that you are listening to the community besides being so busy 🙂

[vapid raft]

For example mocks for all the dependencies could be auto generated from the where description of the mocked class.

[vapid raft]

Would Mojo support contracts or dependent types and test generator