Hello. I brought this up during the recent EFL Dev Day and we discussed it a bit.
Now I want to bring it here for wider discussion and give everybody a chance to have its say. Background is that we struggle to have a good testing coverage with unit tests of our code base. We have initiatives to improve this (which is very much welcome!) but we also need to address one of the root causes here. If you look at our current test coverage status you will see that some parts are way better than others: https://build.enlightenment.org/view/Test%20Coverage/ When we bring new EAPI's we should try as hard as possible to have good unit tests committed together with the new EAPI's. I want to make this mandatory for cases where unit tests are possible. Cases which have specific hardware requirements or need interaction might be harder and I'm willing to accept the fact that sometimes it is almost impossible. But in many many of our newly added EAPI's added units tests for them is doable. Libs like eina, eo, eolian and eet should be straight forward. What I propose is that we have it mandatory to add test cases for new EAPI's and add an explanation to the commit message if you do _not_ submit the unit tests and give a technical reason for it. What do you folks think about it? The feedback I got during the dev day was people are happy with it as long as it covers valid exceptions. regards Stefan Schmidt ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
