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
-
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