[Feature Request]: Adding Test Codes

[KC-2001MS]

Summary

By adding test code, you can verify that the code works properly. It is also possible to find defects.

Pain points

Currently, you have to check whether a program is operating according to specifications, whether it is due to your implementation, or whether it is due to a bug.
This feature will make it easier to check the general operating status.

Considered Alternatives

• Write the documentation to show which parts of the system work
  With this method, each person needs to write and check the code to confirm that it works. Note that this is an inconsistent operation check. It also requires time and effort to write documentation. Once the test code is implemented, there is no need for everyone to write the code again.

Is this a breaking change?

No

Library Examples

No response

Additional Context

The following items would need to be considered

• Is it necessary to make this change now?
  I think it should be done when the framework design is finalized. We do not want to rewrite the test code too often.
• To what extent the test code needs to be implemented
  In my opinion, it is sufficient to test that it can be executed without throwing errors and that it returns values. I am concerned that writing too much test code will make it difficult to maintain.
• Which testing framework to choose?
  I think Swift Testing is the best choice for this package, but the problem is that the official version supports Swift 6.0 or later. There may be an option to use other open source testing frameworks.
  If you choose to implement this using Swift Testing, I would be happy to write this code, even though I know it is not perfect.

[MasterJ93]

This is something that I've been wanting to do for a while, but have keep pushing it back because I don't know where to start. More specifically, I need to better understand how to mock data, which is something I've always been weak at. But you're absolutely correct that this needs to be done and I'll make it more of a priority in the coming days.

As for Swift Testing, as you've mentioned, it's mainly available for Swift 6. Please note that ATProtoKit doesn't fully support Swift 6 yet: while it builds (according to Swift Package Index), there are some race-related errors according to the service. I'm more than happy to have you help in writing unit tests via Swift Testing. That will remove a lot of pressure off of me, so thank you for your willingness to help. I'm tempted to say that we can use XCTest and Swift Testing at the same time (since, as far as I'm concerned, XCTest works on non-Apple platforms as well and it'll work with Swift 5.9), but that might be too much work. For now though, we'll simply stick to Swift Testing and we'll see what additional options we'll have.

I also share your concerns about writing too many unit tests. They will have to be thoughtful but still expansive enough.

[KC-2001MS]

I understood that we are going to try using Swift Testing. I will write as many tests as I can with the Swift Testing framework to familiarize myself with it before making a pull request.
I don't think it's a good idea to prioritize test prep too high, so there's no problem if you implement it slowly. Also, please give me some time to identify issues in implementing the tests.

Finally, I would like your opinion on how far to go with the test after it is ready. In the meantime, I'm going to do the following.

• ATProtocolConfiguration's login-related functions should have detailed test code.
• Other code should be tested only minimally, i.e., not throwing errors and returning values.

[MasterJ93]

Take as much time as you need: I'll leave it up to you, and then I'll refine as we go along.

We'll need to mock the data since testing using online requests would be a bad idea. Due to this, I'll open up APIClientService so that it's easier to test.

With respect to my opinion on how far to go with the tests after it's ready, that's a little bit of an unknown answer. What I mean to say is, I don't know how to fully answer this question, as I haven't thought too deeply into how far it should go. However, What I would like to see so far are the following:

• Each lexicon method should have the most basic functionality tested. In other words, one of the tests will involve testing to see if the API call method will run with the least amount of information. If the method's parameter has a default value, then the test will use the default value. Otherwise, a default parameter is required.
• Each of the methods for APIClientService should be tested: both with correct values and incorrect values.
• For the @DateFormatting and @DateFormattingOptional property wrappers, it should make sure that it can correctly convert between Date and the format that the AT Protocol accepts. It should also be able to successfully make an error if it takes something that doesn't fit within the AT Protocol's specifications (I'll personally handle that one, as it was a tricky thing to solve for me.

That's about everything I can think of right at this moment. I'll think of others as time goes on, but again, it should be thoughtful but expansive.

Please take as long as you need. If you need breaks, please do so. You're not obligated to do this, but again, I appreciate taking time off of your busy schedule to do this.