Hello. On 11/05/15 16:57, Stefan Schmidt wrote: > Hello. > > On 09/04/15 14:34, Stefan Schmidt wrote: >> Hello. >> >> On 01/04/15 14:30, Stefan Schmidt wrote: >>> 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. >> The feedback I got was only positive and after over a week everybody >> should have been able to say if he/she disagrees. >> >> If you bring in new EAPI's it is mandatory from now on to add test cases >> for them. If you tried and failed due to technical problems describe in >> the commit message what hindered you to add test cases for them. > While this have been a bit lax while the 1.14 cycle was still going on > for 1.15 we should have an eye on this during reviews. > > I'm running an abi_checker test from 1.14 to latest HEAD to see what got > added so far and which are missing test cases. Be prepared to be > uncovered shortly if you have done that. :) Some pieces are still missing as I have nothign to compare them against ecore-drm and I need to check why elua does not show up)
For the rest I see this new APIs: efl_player.eo.h, libefl.so.1.14.99 efl_player_length_get ( ) efl_player_seekable_get ( ) Tom? eina_crc.h, libeina.so.1.14.99 eina_crc ( char const* key, int len, unsigned int seed, Eina_Bool start_stream ) A test case has been added for this. Weel done. eina_evlog.h, libeina.so.1.14.99 eina_evlog ( char const* event, void* obj, double srctime, char const* detail ) eina_evlog_start ( ) eina_evlog_steal ( ) eina_evlog_stop ( ) Raster, spankies! :P evas_3d_texture.eo.h, libevas.so.1.14.99 evas_3d_texture_atlas_enable_get ( ) evas_3d_texture_atlas_enable_set ( Eina_Bool use_atlas ) Oleksandr, Cedric? If you thing that this new API's can not be tested due to technical limitations please let us know. regards Stefan Schmidt ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
