如何在客户端脚本上使用 doctest?

发布于 2024-08-11 05:38:05 字数 739 浏览 10 评论 0原文

我正在使用 Google Calendar API,创建一些有用的功能。

另一方面,我想正确地进行一些有用的文档测试并开始敏捷开发。

  • 如何编写 doctest,因为每个函数的结果并不是真正可预测的(取决于服务器上的新内容):

    <前><代码>>>>日历 = GoogleCalendar(用户='blabla', 密码='blablabla') >>>>>日历.列表() [电子邮件受保护]的日历列表 0.... ...
  • 如果我不'不想在源代码中留下密码,我该怎么办?

  • 如何为类的所有函数编写测试,而不需要每次都为每个函数编写相同的内容?

    <前><代码>>>>日历 = GoogleCalendar(用户='blabla', 密码='blablabla') >>>>>日历.myFunction()
  • 对于 GoogleCalendar 的每个函数,我必须首先创建对象?

感谢您的帮助

I am playing with Google Calendar API, creating some useful function.

I another hand, I want to do it right puting some useful doctest and starting agile development.

  • How to write doctest since the result of each function is not really predictible (Depending of what is new on the server) :

    >>> calendar = GoogleCalendar(user='blabla', password='blablabla')
    >>> calendar.list()
    [email protected]'s Calendar List
        0. ...
        ...
    
  • If I don't want to leave the password in the source code, How do I do ?

  • How to write test for all the function of a class without writing each time the same thing to each function ?

    >>> calendar = GoogleCalendar(user='blabla', password='blablabla')
    >>> calendar.myFunction()
    
  • For each function of GoogleCalendar, I will have to create first the object ?

Thank you for your help

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

毅然前行 2024-08-18 05:38:05

如果您决定测试外部服务,则可以使用测试装置:

  • 编写 make_test_server() 函数,该函数将返回一个新的服务器连接以简化您的测试。
  • 使其成为具有可预测输出的测试装置(服务器的虚拟)make_dummy_test_server()
  • 对其进行测试,并确保考虑到所有情况(连接错误、返回空集)。

这取决于您的测试应该有多详尽。如果您从该代码区域发现很多错误,那么您可能需要更多测试。如果你的代码可以工作,那么可能就不值得费力了。

您也在进行代码审查吗?系统测试?单元测试很棒,但请确保您不要目光短浅。

If you do decide to test an external service, you can use a test fixture:

  • Write a make_test_server() function, which will return a new server connection to simplify your tests.
  • Make it a test fixture (dummy of the server) make_dummy_test_server() with predictable output.
  • Test it, and make sure that all cases (connection errors, empty set returned) have been thought of.

It depends on how exhaustive your tests should be. If you are getting a lot of bugs from that area of code, then you might need more tests. If your code works, it might not be worth sweating.

Are you also doing code reviews? Systems testing? Unit testing is great, but make sure that you don't get too myopic.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文