[flutter_tts] Add integration tests for the supported TTS APIs#1041
[flutter_tts] Add integration tests for the supported TTS APIs#1041seungsoo47 wants to merge 4 commits into
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the Tizen implementation of the flutter_tts plugin to version 1.6.1. Key changes include modifying isLanguageAvailable to return a boolean instead of an integer, and adding a comprehensive suite of integration tests. The review feedback suggests optimizing the test suite by using setUpAll instead of setUp to avoid redundant 2-second initialization delays, and adding assertions to verify that lists of languages and voices are not empty before accessing their first elements to prevent uninformative StateError failures.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| testWidgets('stop returns 1', (WidgetTester tester) async { | ||
| await flutterTts.speak('Hello, world!'); | ||
| expect(await flutterTts.stop(), 1); | ||
| }); | ||
|
|
||
| testWidgets('pause returns 1', (WidgetTester tester) async { | ||
| await flutterTts.speak('Hello, world!'); | ||
| expect(await flutterTts.pause(), 1); | ||
| }); |
There was a problem hiding this comment.
After calling tts_speak(), tts_stop and tts_pause are called immediately in c-api code.
If a timing issue occurs and tts_speak is delayed while in the TTS_STATE_READY state, it is unlikely that it will always return 1.
| final voices = await flutterTts.getVoices; | ||
| expect(voices, isNotNull); | ||
| expect(voices, isNotEmpty); |
There was a problem hiding this comment.
I'm just wondering, I think getVoices might not be available depending on the environment. (Currently, our target always has voice, but there could be multiple building blocks.) Is this test case valid? Usually, in cases like this, wouldn't you test by mocking getVoices?
There was a problem hiding this comment.
Integration tests run against real devices or specific emulators where the TTS engine is always present. If 'getVoices' returns empty, it means the device or emulator is not properly configured for TTS, which is a valid test failure.
| SendResult(flutter::EncodableValue(true)); | ||
| return; | ||
| } | ||
| } | ||
| SendResult(flutter::EncodableValue(0)); | ||
| SendResult(flutter::EncodableValue(false)); |
There was a problem hiding this comment.
Since this part is a change to the interface (Future<int> -> Future<Bool>), I think the version needs to be changed to 1.7.0.
isLanguageAvailable returned the integer 1/0 on Tizen, whereas other platforms return a boolean. Return true/false instead so the result type matches the flutter_tts API contract across platforms. Bump the version accordingly. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
flutter_tts has no integration tests upstream, so add regression tests covering the Tizen-supported parts of the flutter_tts v4.2.5 API (per the plugin's "Supported APIs"): - speak / stop / pause return 1 - getLanguages returns a non-empty list - isLanguageAvailable is true for a supported language - setLanguage returns 1 for a supported language - getVoices returns a non-empty list - getDefaultVoice returns a voice - setVoice returns 1 - setSpeechRate returns 1 - setVolume returns 1 - getMaxSpeechInputLength is positive (calls stop() first so the engine is in the ready state that tts_get_max_text_size requires) The isLanguageAvailable test passes thanks to the boolean-return fix in the previous commit. Validated on a Tizen TV (10.0) and Raspberry Pi 4: all tests pass (12 passed, 0 skipped, 0 failed). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- Use setUpAll instead of setUp to initialize the TTS engine once, reducing total test time by ~22 seconds (12 tests × 2s delay) - Add tearDown to call stop() after each test to reset engine state - Add explicit isNotEmpty assertions before accessing list elements in isLanguageAvailable, setLanguage, and setVoice tests Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Remove speak() call before stop() test: speak() returns as soon as tts_speak() is queued, so PLAYING state is not guaranteed when stop() is called; stop() is valid from any non-NONE state regardless - Remove pause() test: tts_pause() only works from PLAYING state and there is no reliable way to wait for that transition in an integration test - Bump version to 1.7.0: isLanguageAvailable return type changed from int to bool, which is an interface-level change Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
seungsoo47
force-pushed
the
flutter_tts-add-integration-tests
branch
from
20567d3 to
4f36aa8
Compare
2 participants
flutter_tts has no integration tests upstream, so add regression tests covering
the Tizen-supported parts of the flutter_tts v4.2.5 API (per the plugin's
"Supported APIs"):
the ready state that tts_get_max_text_size requires)
The isLanguageAvailable test is fixed to return a boolean value.
Validated on a Tizen TV (10.0) and Raspberry Pi 4: all tests pass
(12 passed, 0 skipped, 0 failed).
#1039