×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

INDI Testing Framework

  • Posts: 24
  • Thank you received: 6
Hi there,

I'm new around here. I just forked on Github to add a new USB based Focuser (HitecAstro DC Focuser) and will PR on Github once I have finished and tested it.

But, regarding this thread, I have a lot of experience with the Google Test Framework and it's associated Google Mocking system for C++. If you want a hand I'd be happy to help out.

--Andy
The following user(s) said Thank You: Jasem Mutlaq, Oleg
7 years 9 months ago #8634
The topic has been locked.

Replied by Jasem Mutlaq on topic INDI Testing Framework

Hi Andy,

Great! How can we get started? Can you add the initial skeleton needed to get this rolling? We probably needed separate test trees for core library + drivers
7 years 9 months ago #8639
The topic has been locked.
  • Posts: 24
  • Thank you received: 6

Replied by Andy Kirkham on topic INDI Testing Framework

Hi Jasem

I've been having a look over the code. In addition to getting the framework right I'd also like to get it onto Travis CI. C++ projects are known to be a little bit more tricky than most other project types but I see first up your CMAKE version is 2.6. For the time being this is good as standard Travis without fiddling to much is 2.8.

The first step is to select the lowest hanging fruit to write a UT for. To achieve that we'll have to refactor to pull in the needed frameworks for GT and GM so this will involve some messing around with the CMakeLists.txt files. I will look at doing that over the next day or so in a Github fork.

On a side note, since I am new, I have no idea if you maintainers have discussed adopting a framework such as Qt5? Reason I ask is deep frameworks like this help an awful lot when moving to a CI/CD style system. This is because if you start building standard OS support components then you have to write unit/integration tests for them. However, you never have to unit test a component from say Qt5 because they UT them themselves so you avoid a load of wheel reinventing.

Also, Qt5 is cross platform, once Linux is stable we can look at, err, taking on other OS systems. On WIndows it's ASCOM, on *NIX it's Indi. Why not have a common one. ASCOM can never come to *NIX (natively) due to it's total reliance on .NET. Anyway, I'm just asking the question here, feel free to slap me down if this conversation has already been thrashed out in your community :)

--Andy
7 years 9 months ago #8644
The topic has been locked.
  • Posts: 456
  • Thank you received: 76

Replied by Derek on topic INDI Testing Framework

Well, count me in for writing some tests anyway.
7 years 9 months ago #8646
The topic has been locked.
  • Posts: 193
  • Thank you received: 46

Replied by Gerry Rozema on topic INDI Testing Framework


IMHO, indi is already overloaded with external framework stuff, and burying it inside something that is a graphical setup takes it WAY outside the scope of a lightweight environment to serve devices. I used to run it on rather lightweight devices (mips processor, 4 megs flash, 16 megs ram), but when you start bringing in things like dependancies on boost (already in indi) and potentially larger things, this becomes out of the question.

QT et all are probably acceptable for client software with graphical interfaces etc, but, to bring in that kind of dependancy at the device driver layers is bringing in way to much overhead for no gain.
Last edit: 7 years 9 months ago by Gerry Rozema.
7 years 9 months ago #8647
The topic has been locked.

Replied by Jasem Mutlaq on topic INDI Testing Framework

I'm probably the biggest fan of Qt5 around here, but we've had the Qt discussion before and we determined that it is best to keep the footprint minimal as it is. Also, even if we migrated to Qt5, most of the complex drivers have to be re-written using the platform-specific SDK. It is not an easy task.

Qt5 is very modular, you don't need to the QtGUI component at all if you plan to just run a server. You can select which component you need for your project. Also, IIRC, only 3rd party libapogee needs boosts, INDI lib itself does not use boost.
7 years 9 months ago #8648
The topic has been locked.
  • Posts: 24
  • Thank you received: 6

Replied by Andy Kirkham on topic INDI Testing Framework

ok, understood, just thought I would ask. The only reason I did is experience has shown that adding UT/CI does in fact grow your codebase not matter how much you dislike writing code in the app just to support a UT. For example, a driver using tty_connect (and associated functions, read, write, etc) is difficult to unit test in a sandbox. You need to add "something" that will respond in a repeatable manner and this is often an instance of what you want to test. You have simulators that help reproduce situations but they tend to be more human related than lending themselves to automation. Using frameworks such as Qt5 etc have already solved many of these problems.

But, point taken, I'll start as simple as possible. I have got to a point with my driver for the HitecAstro focuser where I can commit it and put it aside for now. So I will make a start this evening on getting a basic test framework in place and hopefully Travis CI also.
7 years 9 months ago #8650
The topic has been locked.
  • Posts: 193
  • Thank you received: 46

Replied by Gerry Rozema on topic INDI Testing Framework

I know that boost was only required for one driver, but, it's just an example of how these things can cause huge code expansion inadvertently.

In my 'ideal world', newer more modern things like cameras with an ethernet port should be able to export an indi interface directly on the ethernet. These things are typically built using a highly optimized processor with minimal resources, and I know of at least one, possibly more, that do so using an embedded linux inside the camera. In environments like that, one is often dealing with non-mainstream processors running a linux load that is based on 4 megs of flash, with only 16 megs of ram available, more for a much larger sensor, but the majority of on board ram is needed to support image storage.

I work with embedded systems like that on a daily basis, not astronomy gadgets in general, and it becomes a serious issue at times when trying to bring specific packages into the embedded processor environment. I have on numerous occaisions responded to requests for a specific package to be made available to a specific router in the openwrt embedded build, and the response is 'cant, it wont fit in the flash'. Openssl is an example, it's just not possible to squeeze that into a minimal system and leave enough space to allow for other useful things.

My main point is, watching for unnecessary bloat is important in the long run.
7 years 9 months ago #8656
The topic has been locked.
  • Posts: 24
  • Thank you received: 6

Replied by Andy Kirkham on topic INDI Testing Framework

Gerry

I understand your pain. A couple of years ago I worked in Smart Meter embedded systems and ECC encryption was used there rather than RSA for exactly the reasons you outlined. But generally when discussing embedded systems "everything counts". Even the use of C++ with STL rather than C/diy.

I take it on the UT/CI side you are not too bothered about what gets used third party so long as any additional dependancies are only for the UT itself and not the application run time/deliverables?
7 years 9 months ago #8658
The topic has been locked.

Replied by Jasem Mutlaq on topic INDI Testing Framework


Exactly.
7 years 9 months ago #8659
The topic has been locked.
  • Posts: 60
  • Thank you received: 7

Replied by Ian on topic INDI Testing Framework

+1
Even for KStars/Ekos. I don't know how people have got on but I've seen several people posting of forums about running KStars/Ekos on e.g. RPi3s or intending to try or wanting to. No idea if it worked or not but it is a major strength of the Indi software that it requires low resources enabling it to be run on smaller less powerful systems.

I know of two major astro packages that are "held-up" in the beta stages all/part of which is an upgrade to Qt5. One of those packages (a significant offering from a specialist astronomy supplier who has a professional employed s/w development team) has been in the process of upgrade previous Qt version to Qt5 for 3 years now - no new functionality, just upgrade to Qt5. I'm a beta tester for it and last beta release, 1st testing session I had several pages of bugs. Expensive s/w as well. You can end-up running to stand still. Not a criticism of Qt, just "why"? Virtual Machines seem to work for higher end non-Linux hardware and still allow for lower end machine support.

Ian
7 years 9 months ago #8686
The topic has been locked.
  • Posts: 24
  • Thank you received: 6

Replied by Andy Kirkham on topic INDI Testing Framework

3 years? :ohmy: If that's the case then I question the words "professional" and "team" appearing in the same paragraph.

Regarding my question, ok, understood, frameworks like Qt5 are not coming near Indi. But I will ask this, to some degree or another you do need some dependancy injection to support many types of test environments. How far are you guys willing to go? As an example, injecting a wrapper class for tty so that it can be mocked out. So you don't call tty_connect() (etc) directly but indirectly via a wrapper. That way you can put in a mock calls and track their usage. Is this also off the cards?
7 years 9 months ago #8688
The topic has been locked.
Time to create page: 0.680 seconds