Test framework #69

Open
opened 2019-11-06 15:36:56 +00:00 by lunny · 4 comments
Owner

Once gitea/go-sdk#194 merged, I will send a similar PR to this project.

Once gitea/go-sdk#194 merged, I will send a similar PR to this project.
lunny added the
kind/testing
label 2019-11-06 15:36:57 +00:00
Owner

@lunny since the tests in go-sdk impruve a lot I dont think we nee souch extende tests:

if the go-sdk is tested the tea ony differs to it from user interactions

so the more tests go-sdk will get the less I think we need this

CI shoult take care of lint errors and if it can be compiled ...

Users will report the bugs a CI cant catch ...

@lunny since the tests in go-sdk impruve a lot I dont think we nee souch extende tests: if the go-sdk is tested the tea ony differs to it from user interactions so the more tests go-sdk will get the less I think we need this CI shoult take care of lint errors and if it can be compiled ... Users will report the bugs a CI cant catch ...
Owner

what do you think?

what do you think?
Author
Owner

@6543 I think currently you are right. Because tea is a simple wrap command tool of go-sdk. But I would like to hold this issue because in future, we may add more codes which maybe not tested in go-sdk.

@6543 I think currently you are right. Because tea is a simple wrap command tool of go-sdk. But I would like to hold this issue because in future, we may add more codes which maybe not tested in go-sdk.
Member

I think we still need end-to-end tests, as we repeatedly struggled with commandline flags not being available / loosing their aliases / ...

Also newer features add some non-trivial git code, which would be nice to be tested.

The most basic test "framework" I can think of that would get us a long way, is calling the executable with different flag configurations and checking the exit code.
For git operations we could verify correct operation with actual git commands.

I think we still need end-to-end tests, as we repeatedly struggled with commandline flags not being available / loosing their aliases / ... Also newer features add some non-trivial git code, which would be nice to be tested. The most basic test "framework" I can think of that would get us a long way, is calling the executable with different flag configurations and checking the exit code. For git operations we could verify correct operation with actual `git` commands.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: gitea/tea#69
No description provided.