Hi Zheng Wu,

Hmmm, I'm trying to clarify this test case...
According to the Bluetooth device API spec, stopDiscovery API "stops an active device discovery session".
https://developer.tizen.org/dev-guide/2.2.1/org.tizen.web.device.apireference/tizen/bluetooth.html#stopDiscoveryidp241176
So AFAIU if there is no active discovery session, I directly raise an error.

I will have a look and let you know.

Thanks,
Corentin

On 07/09/2014 10:37 AM, Zheng, Wu wrote:

Hi corentin,

I meet an issue when I TCT test.

1.In the file of bluetooth_instance_capi.cc, the function of "voidBluetoothInstance::HandleStopDiscovery" will check the value of "is_discovering"

When is_discovering is zero, the function of "voidBluetoothInstance::HandleStopDiscovery" will return o["error"] = picojson::value(static_cast<double>(1));.

However, is_discovering is zero means that discover stops. It matches the function of HandleStopDiscovery stopping discovery.

The value of o["error"] should return 0;

2.In the process of TCT testing, the value of o["error"] = 0 is right too, or it will block some test cases.

What do you think?

3.BTW, I am checking your patches in Tizen.org too.

Best Regards

Zheng Wu

*From:*[email protected] [mailto:[email protected]]
*Sent:* Tuesday, July 8, 2014 3:55 PM
*To:* Zheng, Wu
*Cc:* Le Foll, Dominique; Xu, Martin; Jia, Pei P; Gu, Chao Jie; Wu, JiangboX; [email protected]
*Subject:* Re: [NTB] TCT testing bug

Hi Zheng Wu,

On 07/08/2014 04:34 AM, Zheng, Wu wrote:

    Hi corentin,

    TCT testing is very important for us.

    Only after finishing the related TCT testing, Bluetooth-Frwk will
    be accepted by Tizen.og.

From my point of view, you also need a way to handle user popups before getting accepted in Tizen.org... The current syspopup implementation is not compliant with Tizen Common and IVI (at least because of the X dependency). It appears to me necessary to fix this before getting accepted in Tizen.org.

    Therefore,  can you debug TCT testing with us after finishing
    notification-service.

Yes, sure ! I will deliver a new proposal of the Tizen:Common NTB plugin using notification API soon.
Then during the code review, I could help on TCT testing.

    Some issues are related with tizen-extension-crosswalk.

Yeah, I'm aware that many of TCT test failures occur due to tizen-extension-crosswalk. I will fix them as soon as I can.
Don't hesitate to let me know bugs you met.

    We hope finish TCT testing as soon as possible too.

FYI 'health' profile related Web API is not yet integrated in tizen-extension-crosswalk.
I've planned to do it in a second step.

    Best Regard

    *From:*[email protected]
    <mailto:[email protected]>
    [mailto:[email protected]]
    *Sent:* Friday, July 4, 2014 11:40 PM
    *To:* Zheng, Wu
    *Cc:* Le Foll, Dominique; Xu, Martin; Jia, Pei P; Gu, Chao Jie;
    Wu, JiangboX; [email protected] <mailto:[email protected]>
    *Subject:* Re: [NTB] TCT testing bug

    Hi Zheng Wu,

    You're right ! I've sent a fix about
    setChangeListener/unsetChangeListener API.
    You can find the patch here:
    
https://github.com/eurogiciel-oss/tizen-extensions-crosswalk/commit/0539f4536750bc3f9904df6e5ba207a9e4321105

    Btw, I saw there are many blocked timeout issues.
    Sorry I can not perform and fix TCT issues on my side because I'm
    focalized on making NTB compliant with Tizen Common (using
    notification-service)...

    Best regards,
    Corentin


    On 07/04/2014 12:23 PM, Zheng, Wu wrote:

        Hi Corentin,

        1. We are testing Bluetooth TCT cases. We meet many blocked timeout 
issues.

        The following issue has been checked by us.

        2. In the test case of 
BluetoothAdapterChangeCallback_onnameChanged.html,

        we found that adapter.setChangeListener is registered.

        After 180000ns, if the cases can't get SetName successfully info from 
the listener of adapter.setChangeListener,

        It will be blocked timeout.

        adapter.setChangeListener is implemented by 
bluetooth_instance_bluez5.cc in tizen-extensions-crosswalk.

        No any Bluetooth CAPIs is invoked in the listener process.

        Can you check why the test case can't get the info from listener? 
Thanks.

        It blocked many test caases.

        Best Regards

        Zheng Wu


_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev

Reply via email to