AF Style Question

[Taggart]

---

@BertMcMahan wrote:
Oftentimes the overarching principle is quite clear but getting from "general SOLID principle" to "working code" is, for me at least, quite hard!

In that vein, any best practices on testing AF-based systems? I am really struggling with that. In this project I inherited there are no tests, so I struggle when I make changes to verify that I didn't break anything. I pretty much have to build and deploy it, and then have the end user run it to know for sure.

Less than ideal. It's slow. When I do make a mistake the customer immediately notices. Also without a safety net I'm afraid to make any large changes or even do any kind of normal small refactorings. Any thoughts?

The only good thing I can say is that it will it will run without the hardware connected, so I can at least run it and make sure it runs. I also have an automated build setup so if I break the build, I know that, but if I break some feature, but it still compiles and runs? I only find out when I get a confused email from the customer about why it doesn't work anymore.

[t.kendall]

Well we have a big advantage on you, the AF based system we are working on has no real GUI's(aside from launcher). It mostly runs on RT (cRIO and PXI) but we do have a windows flavor of it. 

Most of our tasks are DAQ of some sort (DAQmx, Modbus, Xnet, RS-232) so instead of putting a while loop in actor core we use messages to get each DAQ reading now.  The exception being if we need to use a timed loop.  But we have found that for some things (DAQmx Analog input actor for example) you can use some other throttle such as wait for DAQmx clock(monitored in a nested actor).  You obviously have to be careful to design the system such that you don't have bunch of messages stacked up.  So generally now our teams rule is that as long as there is no need for a timed loop to throttle the timing or a very large number of expected messages that we try and use messaging actor instead of an ActorCore.  It has led to Actors which do a lot less than before, but that is a SOLID S.

[AristosQueue (NI)]

---

@Taggart wrote:

In that vein, any best practices on testing AF-based systems?

---

The new AF cust ed course adds a whole new chapter covering exactly this. I'd data dump it here, but it isn't exactly the kind of content that is amenable to a quick post.

[felipefoz]

---

@AristosQueue (NI) wrote:

---

@Taggart wrote:

In that vein, any best practices on testing AF-based systems?

---

The new AF cust ed course adds a whole new chapter covering exactly this. I'd data dump it here, but it isn't exactly the kind of content that is amenable to a quick post.

---

Fresh content? 😃

Looking forward to it.