Create functional testing files and ci process

[andrewtavis]

Terms

• [x] I have searched open and closed issues
• [x] I agree to follow Scribe-iOS' Code of Conduct

Issue

Testing for Scribe and a continuous integration process would be very helpful to assure that pull requests can merged without issue. Discussions of best practices as well as how best to integrate the process into pull requests would be a first step in this issue. This would be followed by writing tests for a baseline, and then adding a ci.yml file to a workflows directory in Scribe-iOS/.github.

[andrewtavis]

The issues with Scribe not functioning as on Simulator means that testing should be a priority, potentially even for the next release. Specifically #96 seems difficult to test for on Simulator. One option going forward would be to integrate a device testing service like Browserstack, which is available free for open source. There's also the ability to add GitHub Actions integration, which then could function as a part of the general CI process.

[SaurabhJamadagni]

Currently reviewing the following documentation @andrewtavis. Docs:

• Apple's XCTest docs

Articles:

• Unit testing in Swift: Fundamentals
• Getting started with Unit Tests in Swift

Will have a brief summarisation by EOD. Also, checking out Browserstack. Thank you for creating all the issues 😄 🚀

[andrewtavis]

You’re welcome for the issues, @SaurabhJamadagni! We can talk tomorrow if more are needed 😝😅😊

And thanks for looking into all this :) I’ll assign the both of us for research and implementation 🙃

[SaurabhJamadagni]

Hey @andrewtavis, sorry for the delay but here's a brief summarisation of the basics from the articles and docs:

• We will first need to define a testing target. Each keyboard should get its own testing target, something similar to what we had seen while trying to debug. We were unable to run a breakpoint if it was directed at the wrong target.

• A subclass of XCTestCase contains test methods to run in which only the methods starting with “test” will be parsed by Xcode and available to run.

  • The naming convention for the testing class is "ClassnameTests".
  • The functions are by convention named as "testWhatTheTestShouldAssert"

• Testing is primarily using the XCAssert function. Although, vanilla XCAssert won't give the most clear explanation of why a test failed. Using the right XCAssert method can help fixing the problem easier.

  • They might produce the same outcome but test for different things.

  • XCTAssertTrue, XCTAssertFalse, XCTAssertNotEqual, XCTAssertEqual, XCTAssertNil and XCTAssertNotNil are some of the commonly used XCAssert functions.

• For each unit test function you will see an empty diamond shape in the gutter on the line of the function declaration. Clicking this diamond will run the specific unit test.

• Parameters used in multiple test methods can be defined as properties in your test case class. You can use the setUp() method to set up the initial state for each test method and the tearDown() method to clean up.

  • An example could be generating a user defaults instance to use for unit tests. Doing so ensures you’re not manipulating the standard user defaults used during testing on the Simulator.
  • These functions are called before and after each of the test functions, respectively. This allows us to set up prerequisites before the tests are being run and to clean up any mess we’ve made after the completion of each unit test.

• Use @testable which is a flag at compilation to access private declarations at testing without having to modify source code. (I don't completely understand how to use this yet, but thought should list anyway. Will update if I get more information)

  • This flag goes is attached to the import statement of a target. Ex:

    import XCTest
    @testable import TestTarget

• What I learned about Test Driven Development (TDD) is that whatever function we want to test, the first step would be list out all possible cases before going to implement the logic. This includes listing out the extremities as well.

I came across a library known as Nimble, which is apparently popular for asserting instead of the standard XCAssert functions. Going through it and will check if there are any advantages to using it over the native functions.

[andrewtavis]

Thanks, @SaurabhJamadagni! Will read into this all a bit when I’m back 😊😊