Testing topic

Testing Made Easy

Flutter supplies the means to test your source code right away. This topic will introduce the test files used to regularly test the Fluttery Framework package itself. It's hoped this overview will give you an appreciation of how easily testing your own code can be in Flutter.

Contents
widget_test.dart	Test with Tester	App Tests	Structured Testing	Setup Testing

widget_test.dart

Below is a screenshot of the widget_test.dart file that runs every time the Fluttery Framework package is about to be released with its latest changes. Much of the Fluttery Framework's functions and features are tested to assure no errors occur as a consequence any changes made. The video below depicts that testing being performed when this Dart file is simply run in an IDE. Both integration testing as well as unit testing is involved in the process.

As you see in the screenshot below, the example app's main widget, FlutteryExampleApp, is instantiated in the Lambda function, testWidgets. It's the very widget you'd see passed to the runApp() function: void main() => runApp(FlutteryExampleApp());. Not only is the app started up, but its main controller, ExampleAppController, is assigned to the variable, con. This is done, in this case, to read its property, .application, so to proceed with the integration testing using the very three small example apps that accompanies the Fluttery Framework package.

widget_test.dart

Test with Tester

The screenshots below displays the counterTest() function and the contactsTest() function that are eventually called in the widget_test.dart file. Both take in the WidgetTester object, tester. It serves as the active agent in the test environment performing the virtual 'pressing of buttons', the 'swiping of screens' and all the other necessary interactions with the very widgets being tested. The test environment also supplies a conglomerate of Finders using the constant, find(), as well as the high-level function, expect(), to both isolate and test particular widgets for expected outcomes. If, at any point, such a test fails the whole testing process stops and reports the issue.

counter_test.dart	contacts_test.dart

App Tests

The first screenshot below highlights the data property referenced in the first screenshot above. Note, because the controllers in this app use factory constructors allowing only one single instance of a particular controller class, they can be readily used in such test environments to, in this case, confirm the counter app has had its button pressed nine times. You see, this CounterController object has the public property, data, incremented and then tested for the expected count.

The second screenshot is that of the _deleteContact() function called in the second screenshot above. It demonstrates how you're free to use a static property from the app itself to contribute to its very testing. In this case, the property, App.useMaterial, is utilized to determine which interface design the app is current running in (Material or Cupertino). This property comes from the App class and will be available to you the next time you write your app with the Fluttery Framework.

counter_controller.dart	contacts_test.dart

Structured Testing

There are currently some 52 test files involved with the Fluttery Framework package. Admittedly, not all are fully implemented, but with that number of Dart files, there had to be some organizing involved. The screenshot below conveys the directory structure used to contain these test files. Among these test files, there are a number of 'export' files (named with leading underscores) that collect, in a way, all of them together.

The screenshot also reveals the reams of export statements that can be found in one of these export files listing out the test files contained in various folders. That file and two others are listed below for your perusal:
_unit_test_view.dart
_unit_imports.dart
_test_imports.dart.

This all follows the Dart team’s own approach to organizing a library package

_test_imports.dart

With 'export' files, instead of your Dart files listing dozens of import statements, you have just one or two 'import' statement taking in all that code. The first screenshot below, for example, lists all the code taken in by the file, unit_tests.dart, in the second screenshot. As a result, just one 'import' statement is necessary to complete the unit testing here. Very nice.

_unit_imports.dart	unit_tests.dart

Setup Testing

Below are screenshots of the Fluttery Framework's pubspec.yaml file. You'll see highlighted the settings necessary for testing. For example, the libraries, flutter_test and integration_test, have to be introduced into your pubspec.yaml file. Unlike Fluttery Framework, for your app, place flutter_test library under the heading, dev_dependencies:.

pubspec.yaml	pubspec.yaml

Further documentation on setting up and getting started is available to you at flutter.dev:
An introduction to widget testing
Testing Flutter apps