log refactoring for issue #107 #108
yongchin0821
started this conversation in
General
Replies: 2 comments
-
从另一个项目 之前的重构失败的原因是 修改stdout和stderr耦合性太强,本质上是一种破坏性修改,当不使用XTestRunner时,也会跟着受影响,导致整个log模块失效。 本次修改的思路是,seldom把logger传入XTestRunner,在XTestRunner那边进行判断修改。 这就做到了使用XTestRunner时,XTestRunner自行收集log模块的信息,而不使用XTestRunner时,log模块又不会受到影响。 |
Beta Was this translation helpful? Give feedback.
0 replies
-
🚧 以前的不足:
💡 修改的思路:隔离seldom和XTestRunner,seldom就只负责使用,XTestRunner负责收集 ✨ 现在的状态seldom 现在能自由使用 loguru的logger实例的所有方法(例如 本轮是一次较为满意的修改 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
About this issue #107
不管在什么地方调用log.debug(),输出日志的
{file}
总显示为log.py
为什么会造成这种现象
log.py对loguru进行了封装,而为了让日志被记录在HTML报告中,Logger类又重新封装了debug()、info()等方法,把print()和logger.debug()包裹在了一起
现在看来事实上这样并不太好,因为logger.debug()写在了
log.py
里面,这样会导致外层调用debug()、info()等方法的时候,控制台输出的{file}
永远是log.py
seldom面临的问题
{file}
永远为log.py
所以一定程度上print()和log.debug()的混用给seldom的自身封装和外部调用使用都造成了困扰和不便
我们是否通过修复问题1,从到让问题23也迎刃而解
如何解决这个问题
通过深入了解研究,在个人看来,在seldom log这边去兼容XTestRunner的报告是很被动的。
原因在于XTestRunner在每个用例执行时会收集控制台信息,每次都会把sys.stdout和sys.stderr放进StringIO缓存区。print()相关内容会被吃掉收集到StringIO缓存区里面,最后在通过getvalue()取出。
因为seldom执行顺序的关系,loguru会先实例化logger,这时使用的sys.stderr和后面XTestRunner的sys.stderr不是同一个。(简言之sys.stderr不是响应式状态,导致logger和XTestRunner不在同一个频道上)
现正尝试在 seldom 的
dev-log
分支和 XTestRunner 的dev-log
分支上进行优化。大致思路是seldom的log会先备份sys.stderr,然后新开一个StringIO 的handler,XTestRunner那边先判断sys.stderr是否为StringIO,是的话则接收,不是的话则是走自身原来的逻辑。
修完改成后,通过seldom根目录下的test_log.py进行了自测,目前看起来是没问题的。(这种解决方法可能不是完美的,后续会从XTestRunner独立使用的独立性,和与seldom联合使用兼容性上持续关注是否存在新问题)
Beta Was this translation helpful? Give feedback.
All reactions