On Tue, 12 May 2015 04:55:40 +0000 Sebastian Dransfeld <sebastian.dransf...@gmail.com> said:
> tir. 12. mai 2015, 01:13 skrev Carsten Haitzler <ras...@rasterman.com>: > > On Mon, 11 May 2015 17:06:36 +0200 Stefan Schmidt <ste...@osg.samsung.com> > said: > > > 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 > > dude - i just added them... i'm still not done. also this is intended for > efl > internal use (see docs). they may be eapi but not meant for use outside of > efl > itself (EPI only because symbols need to be visible). if i could make this > non-eapi and we had a single libefl.so - i would. > > > Hide them with a define? what value does this add? (other than adding more code to have to #define something in every efl file that uses them - and i intend that to be many)? -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ 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
