On Tue, Mar 28, 2017 at 10:40 AM, Andy MacGregor <amacgregor.2...@comcast.net> wrote: > Hi all, > > My name is Andy MacGregor, I'm a 3rd year Computer Engineering student from > the University of Massachusetts, Lowell (currently studying at Czech > Technical University in Prague), and I'm interested in working with RTEMS > for GSOC 2017. > Hello and welcome.
> I have some experience writing unit tests for embedded systems, so I'm > interested in the testing tasks like > #2918(https://devel.rtems.org/ticket/2918#no1) or #2920 > (https://devel.rtems.org/ticket/2920). > > I've read Cillian O’Donnell's GSOC proposal and Amar Takhar's vision for the > direction he wants to take RTEMS testing. > I see two sort of options for myself to fit into this plan. > 1) I could collaborate with Cillian to convert a larger portion of the test > suite > 2) Or I could focus on approaching 100% code coverage for several targets. > > From my perspective it seems more productive to first convert the test-suite > to Unity style testing first before adding test cases. Any thoughts or > suggestions? > The main thing to avoid is any dependency between you and another student. If you can both work productively and create new code in parallel, then #1 can work out. But if it requires close interaction to work, and there is a chance one student causes a bottleneck for another, then there can be some concern. I'm not sure that I've seen a clear requirements statement for the testing framework to understand what is actually needed, and what will be provided. (I'll have to read Cillian's proposal, I haven't read any of them since late last week.) For #2, there is always room for improving our code coverage, and not all of this work means writing new tests. In some cases, it means analyzing the code for problems such as dead blocks or understanding why branches are not taken. In general, we are not opposed to have "clusters" of students working on similar-themed projects. The only real blocker is if there is potential for a strict dependency to occur, where one student has to wait for another. That, we need to avoid. > Thanks for your attention, > -Andy MacGregor > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
