[GSOC] -- Testing Improvements Project

[Gedare Bloom]

On Tue, Mar 28, 2017 at 10:40 AM, Andy MacGregor
<amacgregor.2018 at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel