Testing

We have written several tests to ensure code quality and to detect possible infections. You can find our tests here, here and here.

Testing with Test Data Center by Telegram

Motivation

We use the so-called TDLib (C-library) to communicate with Telegram. By using it we want to ensure that everything works correctly and we have unterstood the usage of the TDLib. This is why we want to test it. But because of authentication-reasons (MFA) we are not able to automate tests by using a normal telegram account. Instead, we use the Test Data Center provided by Telegram.

Test Data Center

Telegram uses several datacenters to manage their data. One of them is a datacenter which is used for development reasons. It accepts specific pairs of phone number and authentication code which will not change. With these codes you will be able to automate your tests.

We use the following specification: phonenumber: '9996612345' authenticationcode: '11111'

How to Test

There are 3 test packages.

• TelegramClientTests-Core for testing the core package
• TelegramClientTests-UI for testing the UI package
• TelegramClientTests-Misc for sar file generation, linter tests and the static data used by all tests (TCTMMocks)

UI Testing

There are two main ways to test UI features

• Morphic Testing Framework
• screenshot tests, compared by hash value.

Both are supported by subclassing TCTUTestCase. For finding and interacting with UI elements or assertions, also see MTFMorphWrapper >> navigating.

Because of bugfixes in morphic TableLayoutPolicy, screenshot tests should be marked as expected failures for the 5.2 pipeline. To do that, add the test name like this:

expectedSqueak5_2Failures
	^ #(#testMessageShrinksCorrectly)

support for 5.2 was dropped in 669655978984ee17e924e68c453a1c5faf55e694

Core Testing

Depending on the tested feature, decide on a fitting mock. Real tdlib connections are pretty slow, which is why the other kinds of mocks are offered (see below).

If you want to test the actual tdlib API, consider using the eventLog of the TestCore.

Mocking

In order to test the Telegram Squeak code, some form of core is always needed. For that, we currently have 3 options:

• TestCore: using a real core with full connection to tdlib (test data center)
• MockTeleClient: using a real core with a mocked tdlib connection that answers events such as specified by the test
• MockCore: using a core without any client, responding with hardcoded data

TestCore

Because connections to tdlib are expensive in time and subject to flood warnings (ddos protection), we decided to try and keep one tdlib core alive. For that, the TCTCCoreResource is used. To include it in a TestCase subclass, use this on class side:

resources
	^ { TCTCCoreResource }

or inherit from TCTCTdlibTestCase. The actual resource instance can then be accessed with TCTCCoreResource current.

To write tests, it can be useful to make assertions over the incoming events from the tdlib and the order of that events. Because of that, the TestCore saves all incoming events in order. To query that log, see loggedEventsSatisfying: and chronologicalPositionOf: in TestCore.

MockTeleClient

To create a MockTeleClient, use self core: (TCCCore newWithTeleClient: (TCTCMockTeleClient new))..

We can imitate tdlib responses to requests by using onRequestType:respond: or onRequestType:respondAll:. When a request with a matching value for @type comes in, the tele client will the respond with the supplied JSON that got specified before by calling one of the methods. If the request had an extra attribute, the TeleClient will automatically match it in the answer.

MockCore

This core does not create any requests nor a tdlib client. You can directly set the chats for instance, with

self core: TCTUMockCore new.
self core chats: TCTMocks mockChats.

Mainly used for UI testing, when testing the core package is not the goal.