[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