[英]Java Log Coverage tool
Are there any tools or strategies for generating a "Log coverage" report on (Java, log4j)? 是否有任何工具或策略用于生成(Java,log4j)的“日志覆盖”报告? Like code coverage, but ensuring that there aren't large methods, classes, or packages which don't log anything.
像代码覆盖一样,但确保没有大型方法,类或包不记录任何内容。
When coding web services, me team doesn't write many log statements. 在编写Web服务时,我的团队不会写很多日志语句。 When debugging a real time problem with running, production code, we always wish we had.
在调试运行生产代码的实时问题时,我们总是希望有。 Inevitably we try to reproduce the bug in our test environment with either a debugger attached or additional log statements added, which can be very difficult depending on the structures and inter-operation involved.
我们不可避免地尝试在附加调试器或添加额外的日志语句的情况下重现测试环境中的错误,这可能非常困难,具体取决于所涉及的结构和互操作。
Does anyone use this as a code-quality metric? 有没有人使用它作为代码质量指标?
Code coverage takes special instrumentation because you're trying to find out whether a piece of production code is exercised by any test. 代码覆盖需要特殊的工具,因为您试图找出是否通过任何测试执行了一条生产代码。 What you're asking is a little more vague and could be either much easier ("is any logging done for this large class?") or much harder to the point of impossible ("did we log the method that's going to break in production?").
你要问的是更模糊一点,可能要容易得多(“这个大类的日志记录是什么?”)或者更难以实现(“我们是否记录了生产中断的方法” ?“)。
For the first question, you could whip up a shell script pretty quickly to do the job. 对于第一个问题,你可以很快地编写一个shell脚本来完成这项工作。 Here's a skeleton in Perl, for example.
例如,这是Perl中的骨架。 Here, I assume that we're using SLF4J and that seeing the import of "LoggerFactory" is enough evidence to assume there's a logger.
在这里,我假设我们正在使用SLF4J并且看到导入“LoggerFactory”足以证明有一个记录器。
while ($filename = shift) {
open my $in, "<$filename";
my $loc = 0;
my $log = "NO LOGGER";
while (<$in>) {
$loc++;
if (m/import org.slf4j.LoggerFactory/) {
$log = "has logger";
}
}
print "$filename : $loc LOC $log\n";
$total{$log} += $loc;
}
print "\n\nTOTAL LOGGED: $total{'has logger'}\nTOTAL UNLOGGED: $total{'NO LOGGER'}\n";
and I can run this from my shell to run over all the Java files in a little project with 我可以从我的shell运行它来运行一个小项目中的所有Java文件
$ find . -name \*.java -exec perl haslog.pm {} \+
This only works for small-sized projects, and it's fairly brittle but it wouldn't be a ton of work to make a more robust version of this. 这仅适用于小型项目,而且相当脆弱,但制作更强大的版本并不是一件容易的事。
Lots of logs can be noise and in my experience I always found tracing through logs painful. 大量的日志可能是噪音,根据我的经验,我总是发现日志记录很痛苦。 Having said that if the logs are managed well you can get good diagnostics/reporting.
话虽如此,如果日志管理得当,您可以获得良好的诊断/报告。 One of the reason for the code not being tested properly is because of having lots of logs in production code.
代码未正确测试的原因之一是因为生产代码中包含大量日志。 What developers tend to do is add a log statement when they are developing to check the code works, consequently it encourages not writing a test with the right assertion.
开发人员倾向于在开发时添加一个日志语句以检查代码的工作原理,因此它鼓励不使用正确的断言编写测试。 What you need is lots of little classes that are well tested composed together.
你需要的是许多经过良好测试的小课程。 The assertion should exactly tell you why the test is failing.
断言应该准确地告诉你测试失败的原因。
Lets say in your code path you are expecting something to happen which is its main responsibility (eg Created a DB entry to register user/or someone logging in), when I say its main responsibility I am not talking about a side effect that happens in your code path. 让我们说在你的代码路径中你期望发生一些事情,这是它的主要责任(例如创建一个注册用户/或登录用户的数据库条目),当我说它的主要责任我不是在谈论发生的副作用你的代码路径。 If you have an error condition in the main code path the exception should be thrown all the way up the stack were you can log and convert that to a user friendly message.
如果主代码路径中有错误条件,则应该在堆栈中抛出异常,您可以将其记录并转换为用户友好消息。 RuntimeExceptions are a good here because you dont want to be catching these exceptions until its all the way up to the view layer.
RuntimeExceptions在这里很不错,因为您不希望捕获这些异常,直到它一直到视图层。 Side effects can be logged as well because they are like info/warnings.
副作用也可以记录,因为它们就像信息/警告。
声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.