On Sun, 15 Jul 2018 12:35:13 +0900 Carsten Haitzler <ras...@rasterman.com> said:
> On Sat, 14 Jul 2018 12:01:34 +0300 Jonathan Aquilina <jaquil...@eagleeyet.net> > said: > > > Where can I begin? > > first step is writing code that uses efl api's. then writing simple mini-apps. > they don't have to have a gui, but tbh to get better coverage at this point > and best "bang for your buck" or "more code paths covered per hour spent on > tests" would probably be exactness. > > https://git.enlightenment.org/tools/exactness.git/ > https://git.enlightenment.org/tools/exactness-elm-data.git/ > https://git.enlightenment.org/tools/exactness-edje-data.git/ > > what exactness does is run an app and record its output at specific time > points (the pixels) as well as feed recorded input into it. if the output > pixels don't match some pre-recorded ones, then something possibly changed - > a bug, or maybe an incompatible change. this will cover a lot of code in such > tests because it drives efl at the higher api levels with a full working > "mini app". e.g. just pop up a window with a list, scroll down, select > something, change the state of a button from disabled to enabled, for > example. you can record multiple input + output sessions with the same > mini-app. > > the reason i suggest this to begin with is that it's going to not require > detailed knowledge of how an api must work (unit tests testing specific pre > and post conditions), and is useful in that the knowledge here can build > actual useful applications too pretty much in full, where writing tests for > "ecore ipc" really only exercises a small subset of useful api (but in gory > detail). > > of course there are the unit tests. they are in src/tests/ ... have a look at > them. grep for main in each dir to find the file(s) that produce the > executables and note how they register each test function, then each test func > may in turn run more tests etc. etc. ... ... add more functions that are not > covered already. note that this is why i suggested the above first as it's > gentler to begin with IMHO. also an interesting article that nicely describes some of the reasons why i favour integration tests first, and why i suggest it as a priority: https://blog.usejournal.com/lean-testing-or-why-unit-tests-are-worse-than-you-think-b6500139a009 > > Sent from my iPhone > > > > > On 14 Jul 2018, at 10:25, Carsten Haitzler <ras...@rasterman.com> wrote: > > > > > > On Sat, 14 Jul 2018 10:00:41 +0300 Jonathan Aquilina > > > <jaquil...@eagleeyet.net> said: > > > > > >> Hi Raster with what you said below and other threads I’ve seen with > > >> people complaining about lack of unit tests etc wouldn’t it be better to > > >> get nightly builds to those that like to be on bleeding edge and help us > > >> test and report bugs. Not to mention I think nightly builds are possible > > >> as I see a lot of things that get committed to the repos on a daily > > >> basis at times. > > > > > > we already have that - jenkins and now travis builds every commit. there > > > is no point building daily if you are building every commit already. > > > > > > the issue isn't the builds, it's the tests themselves. having them cover > > > everything in an efficient and sensible way. in fact lowering the barrier > > > of entry to making a test... that's the work needed. :) > > > > > >> My take like this is engaging the community and user base more. > > >> > > >> Let me ask you this and it’s more to ponder on. How much of the current > > >> user base is on the latest and greatest? > > >> > > >> Sent from my iPhone > > >> > > >>> On 14 Jul 2018, at 08:57, Carsten Haitzler (The Rasterman) > > >>> <ras...@rasterman.com> wrote: > > >>> > > >>> On Fri, 13 Jul 2018 18:51:30 +0300 Jonathan Aquilina > > >>> <jaquil...@eagleeyet.net> said: > > >>> > > >>>> I think it was me not being clear I think what I’m thinking is nightly > > >>>> tar balls and if need be I’m willing to work on pre packaged binaries > > >>>> for nightly builds > > >>> > > >>> TBH fixes don't move into a stable branch fast enough to justify > > >>> nightlies. they go in over time maybe every few days or weeks then every > > >>> now and again a point release goes out with them after a "does it > > >>> compile and pass tests" check. these releases are incredibly easy and > > >>> simple and can be automated, but no point having them nightly - just a > > >>> "we have enough fixes now - push one out" time point. > > >>> > > >>>> Sent from my iPhone > > >>>> > > >>>>> On 13 Jul 2018, at 18:46, Stefan Schmidt <ste...@datenfreihafen.org> > > >>>>> wrote: > > >>>>> > > >>>>> Hello. > > >>>>> > > >>>>>> On 13.07.2018 11:27, Jonathan Aquilina wrote: > > >>>>>> I was even thinking weekly point releases to get any new code or bug > > >>>>>> fixes out for early testing. > > >>>>> > > >>>>> Hmm, not sure I get you here. What I talk about are stable updates > > >>>>> which would only contain fixes. No new code and definitely not used > > >>>>> for testing at the users systems. These should only ship with verified > > >>>>> fixes. > > >>>>> > > >>>>> regards > > >>>>> Stefan Schmidt > > >>>>> > > >>>>> ------------------------------------------------------------------------------ > > >>>>> Check out the vibrant tech community on one of the world's most > > >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > >>>>> _______________________________________________ > > >>>>> enlightenment-devel mailing list > > >>>>> enlightenment-devel@lists.sourceforge.net > > >>>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > >>>> > > >>>> > > >>>> ------------------------------------------------------------------------------ > > >>>> Check out the vibrant tech community on one of the world's most > > >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > >>>> _______________________________________________ > > >>>> enlightenment-devel mailing list > > >>>> enlightenment-devel@lists.sourceforge.net > > >>>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > >>> > > >>> > > >>> -- > > >>> ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > >>> Carsten Haitzler - ras...@rasterman.com > > >>> > > >> > > > > > > > > > -- > > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > > Carsten Haitzler - ras...@rasterman.com > > > > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > Carsten Haitzler - ras...@rasterman.com > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
