Open KC-2001MS opened 1 month ago
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.
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.
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:
APIClientService
should be tested: both with correct values and incorrect values.@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.
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
Is this a breaking change?
No
Library Examples
No response
Additional Context
The following items would need to be considered