From: Yao Qi <yao@codesourcery.com>
To: Vladimir Prus <ghost@cs.msu.su>
Cc: <gdb-patches@sources.redhat.com>
Subject: Re: [RFC] Merge mi-cli.exp and mi2-cli.exp
Date: Mon, 03 Sep 2012 15:55:00 -0000 [thread overview]
Message-ID: <5044D2B6.30600@codesourcery.com> (raw)
In-Reply-To: <k21s1o$aps$1@ger.gmane.org>
On 09/03/2012 05:08 PM, Vladimir Prus wrote:
> Yep, that was the intent -- with the extra twist that tests for MI and
> MI2 are not necessary
> identical. In other words, MI2 tests are tests for MI2 when MI2 was
> declared "done", and the
> idea was that the output with "-i=mi2" would remain the same for years.
> -i=mi is our current
> version of MI, which may evolve, and when MI3 is declared "done", the
> current tests will
> be copied to mi3-* tests to keep backward compatibility in future.
>
mi and mi2 test cases are not necessarily identical, but most of them
should be the same, and the difference should be a small part in test.
I can't see the benefit of simply copying mi tests to mi2 tests.
We can claim that a certain version of MI is done, but I am not sure we
can claim the testing to a certain version or some versions of MI is
done, unless we have a confident coverage result. What should we do if
we want to add more tests to all existing MI? The tests are not
specific to a certain version of MI. Do we have to copy the new tests
to mi-foo.exp and mi2-foo.exp?
I am writing some tests on breakpoint-modified notification on all types
of 'breakpoint', such as watchpoint, catchpoint, dprintf, tracepoint,
etc. I write them in mi-cli.exp, but I am wondering whether I should
add them to mi2-cli.exp as well.
--
Yao
next prev parent reply other threads:[~2012-09-03 15:55 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-31 13:29 Yao Qi
2012-09-03 9:08 ` Vladimir Prus
2012-09-03 15:55 ` Yao Qi [this message]
2012-09-05 0:29 ` Stan Shebs
2012-09-10 20:09 ` Tom Tromey
2012-09-11 15:15 ` Pedro Alves
2012-09-11 21:53 ` Stan Shebs
2012-09-12 15:28 ` Pedro Alves
2012-09-12 13:59 ` Yao Qi
2012-09-19 11:22 ` Yao Qi
2012-09-19 13:47 ` Pedro Alves
2012-09-21 8:40 ` Yao Qi
2012-09-28 0:04 ` [PATCH 0/11] Cleanup MI test cases Yao Qi
2012-09-28 0:04 ` [PATCH 02/11] mi-var-block.exp Yao Qi
2012-09-28 0:04 ` [PATCH 05/11] mi-pthreads.exp Yao Qi
2012-09-28 0:05 ` [PATCH 10/11] mi-stack.exp Yao Qi
2012-09-28 0:05 ` [PATCH 03/11] mi-file.exp Yao Qi
2012-09-28 0:05 ` [PATCH 04/11] mi-basics.exp Yao Qi
2012-09-28 0:05 ` [PATCH 07/11] mi-var-cmd.exp Yao Qi
2012-09-28 0:05 ` [PATCH 11/11] mi-syn-frame.exp Yao Qi
2012-09-28 0:05 ` [PATCH 06/11] mi-break.exp Yao Qi
2012-09-28 0:05 ` [PATCH 01/11] Remove mi-FOO.exp which are identical to mi2-FOO.exp Yao Qi
2012-09-28 0:05 ` [PATCH 09/11] mi-console.exp Yao Qi
2012-09-28 0:05 ` [PATCH 08/11] mi-var-display.exp Yao Qi
2012-09-28 19:36 ` [PATCH 0/11] Cleanup MI test cases Pedro Alves
2012-10-12 9:47 ` Yao Qi
2012-10-12 10:05 ` Pedro Alves
2012-10-14 12:25 ` [committed] : " Yao Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5044D2B6.30600@codesourcery.com \
--to=yao@codesourcery.com \
--cc=gdb-patches@sources.redhat.com \
--cc=ghost@cs.msu.su \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox