[GSOC] -- Testing Improvements Project

Amar Takhar amar at rtems.org
Tue Mar 28 17:01:23 UTC 2017


On 2017-03-28 12:43 -0400, Gedare Bloom wrote:


> 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.

This can work and I have done it for other projects in the past.  What needs to 
happen is the two students need to work on completely separate areas where there 
is no overlap or dependencies.

I can say up-front that the students applying so far lack the knowledge in C to 
do the more advanced tests.  At this point I have received two proposals on 
doing this work.


> 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.)

I am working with Cillian now to firm up their proposal and give an introduction 
to the test suite.  At the moment we are trying to gauge their abilities to 
see what areas are suited for them to work on.


> 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.

Agreed.  Most of this work does not involve writing new tests but there will be 
some required.


> 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.

It's only possible to avoid dependencies between the two if they have vastly 
different abilities with C.


Feel free to email me directly to discuss.


Amar.



More information about the devel mailing list