Java 单元测试
涉及到枚举类型和system.out.println
package com.example.lib;import static junit.framework.TestCase.assertEquals;import org.junit.Test;import java.io.ByteArrayOutputStream;
import java.io.PrintStream;public class TestDemo {@Testpublic void test(){Employee employee = new Employee();assertEquals(Gender.OTHER,employee.getGender());// 创建一个ByteArrayOutputStream来捕获输出ByteArrayOutputStream outContent = new ByteArrayOutputStream();// 将标准输出重定向到ByteArrayOutputStreamPrintStream originalOut = System.out;System.setOut(new PrintStream(outContent));// 调用work0()方法employee.work();// 将标准输出恢复到原始状态System.setOut(originalOut);// 验证输出内容是否符合预期assertEquals("I am coding.", outContent.toString().trim());}
}可以测试时间长的 设置一个限制时间
@Testpublic void testCountPrimesSieve() {// 测试小的数字assertEquals(4, PrimeCount.countPrimesSieve(10));assertEquals(25, PrimeCount.countPrimesSieve(100));// 测试较大的数字assertEquals(78498, PrimeCount.countPrimesSieve(1000000));}@Test(timeout = 5000)public void testCountPrimesSievePerformance() {// 测试较大数字的性能PrimeCount.countPrimesSieve(1000000);}
1. 强制使用特定的命名风格规约：如类名使用UpperCamelCase风格，方法名、参数名等使用lowerCamelCase风格，常量全大写等。
不太赞同或理解的原因：虽然统一的命名风格有助于提升代码的可读性和可维护性，但某些情况下，过于严格的命名规则可能会限制开发者的创造力，特别是在某些小型项目或快速迭代的项目中，过于复杂的命名规则可能会增加开发成本。
2. 禁止使用魔法值规约：不允许出现任何未经定义的常量（即魔法值）直接出现在代码中。
不太赞同或理解的原因：虽然使用魔法值确实会降低代码的可读性和可维护性，但在某些简单逻辑或临时代码中，使用魔法值可能更为直观和方便。此外，过度追求无魔法值可能会导致代码过度设计，增加不必要的复杂性。
3. 接口方法必须加@Override注解规约：所有的覆写方法，必须加@Override注解。
不太赞同或理解的原因：虽然@Override注解有助于发现潜在的继承错误，但在某些情况下，如接口方法实现非常简单或明显时，添加@Override注解可能会显得冗余。此外，某些开发者可能认为这增加了代码的噪声。
4. 强制使用特定的代码格式规约：如大括号的使用、空格和缩进等。
不太赞同或理解的原因：虽然统一的代码格式有助于提升代码的可读性，但不同团队或开发者可能有自己的代码风格偏好。强制使用特定的代码格式可能会引发不必要的争议，并可能降低开发者的效率。
5. 禁止使用特定的类或方法规约：如禁止使用某些被认为是过时或不安全的Java类和方法。
不太赞同或理解的原因：虽然使用过时或不安全的类和方法确实存在风险，但在某些特定场景下，这些类和方法可能是唯一可行的解决方案。此外，随着Java版本的更新，某些被认为是过时的类或方法可能会得到改进或重新引入。
6. 强制使用特定版本的库或框架规约：项目必须依赖特定版本的第三方库或框架。
不太赞同或理解的原因：虽然使用稳定版本的库或框架有助于减少项目风险，但过于严格的版本限制可能会限制项目的灵活性和可扩展性。此外，随着技术的发展和更新，新版本的库或框架可能包含更多的功能和改进。
7. 禁止使用内部类规约（假设存在）：在某些情况下，禁止使用内部类。
不太赞同或理解的原因：内部类在Java中具有广泛的应用场景，如事件监听器、适配器模式等。禁止使用内部类可能会限制开发者的设计选择，并可能导致代码变得复杂和难以理解。
8. 强制使用静态方法规约（假设存在）：在某些情况下，强制使用静态方法而非实例方法。
不太赞同或理解的原因：静态方法和实例方法各有优缺点，应根据具体场景和需求来选择使用。强制使用静态方法可能会忽略实例方法的优势，如状态保持和继承等。
9. 禁止使用try-with-resources语句规约（假设存在）：在某些情况下，禁止使用try-with-resources语句来自动管理资源。
不太赞同或理解的原因：try-with-resources语句是Java 7引入的一个特性，用于自动管理资源，如文件流、数据库连接等。它有助于减少资源泄露的风险，并简化代码。禁止使用try-with-resources语句可能会增加资源管理的复杂性，并降低代码的可读性和可维护性。
10. 强制使用特定的异常处理策略规约：如所有异常都必须记录日志、所有异常都必须抛出等。
不太赞同或理解的原因：异常处理策略应根据具体场景和需求来制定。在某些情况下，记录日志或抛出异常可能是合适的处理方式；但在其他情况下，可能更适合使用其他错误处理机制，如返回错误码、设置错误状态等。强制使用特定的异常处理策略可能会限制开发者的灵活性和创造性。
需要注意的是，以上列出的规约及其原因可能因个人或团队的偏好而有所不同。在实际开发中，应根据项目的具体需求和团队的实际情况来制定合适的编程规范。
1. **命名规约的严格性**- **规约**：类名使用UpperCamelCase风格，方法名、变量名使用lowerCamelCase风格。- **开发者困惑**：某些团队可能有自己的命名习惯，觉得适应新的命名规约需要额外的学习成本。2. **异常处理规约**- **规约**：捕获具体异常，不允许直接捕获Exception类。- **开发者困惑**：捕获具体异常有时会觉得代码冗长，直接捕获Exception似乎更简洁。3. **日志规约**- **规约**：使用slf4j进行日志记录，严禁使用System.out.println。- **开发者困惑**：团队可能已经习惯于某种日志框架，转换到slf4j需要时间和精力。4. **单元测试规约**- **规约**：单元测试覆盖率不低于80%，关键业务逻辑需要100%覆盖。- **开发者困惑**：觉得严格的覆盖率要求增加了开发工作量，尤其是在赶项目进度时。5. **并发编程规约**- **规约**：必须使用java.util.concurrent包中的类，而不是手动创建线程和锁。- **开发者困惑**：对于不熟悉并发编程的开发者来说，理解并使用这些高级类较为困难。6. **注释规约**- **规约**：所有类、方法必须有清晰的注释，特别是公共API。- **开发者困惑**：有些开发者认为过多的注释影响代码美观，并且花费时间维护注释与代码的一致性。7. **代码分支规约**- **规约**：不允许出现超过三层的嵌套if-else结构。- **开发者困惑**：某些复杂业务逻辑可能需要深层嵌套，简化代码结构可能会使逻辑变得分散和难以理解。8. **枚举规约**- **规约**：推荐使用枚举来定义常量而不是使用静态常量。- **开发者困惑**：有些开发者认为枚举的使用有时过于复杂，静态常量更直观。9. **常量定义规约**- **规约**：所有常量都必须使用大写字母加下划线来命名，并且放在一个独立的类中。- **开发者困惑**：觉得单独一个类来存放常量有时显得不够灵活。10. **JavaDoc规约**- **规约**：所有公共方法和类必须包含JavaDoc注释，包括参数、返回值、异常等。- **开发者困惑**：认为过于详细的JavaDoc维护起来麻烦，尤其是当方法较为简单时。11. **集合处理规约**- **规约**：建议使用Collections类中的方法如Collections.sort()进行排序，而不是直接操作集合。- **开发者困惑**：觉得这种方式有时不够灵活，需要额外学习和适应。12. **泛型编程规约**- **规约**：建议在类和方法中使用泛型，避免使用原生类型。- **开发者困惑**：对泛型的深入理解需要时间，对于简单项目可能觉得泛型带来了不必要的复杂度。13. **字符串规约**- **规约**：使用StringBuilder进行字符串拼接，而不是直接用+操作符。- **开发者困惑**：觉得+操作符更直观简洁，在小规模字符串操作时使用StringBuilder显得繁琐。14. **设计模式规约**- **规约**：建议在特定场景下使用设计模式，如单例模式、工厂模式等。- **开发者困惑**：认为在一些情况下使用设计模式显得过度设计，不如直接代码来得简洁。15. **编码实践规约**- **规约**：统一使用四个空格缩进，禁止使用Tab键。- **开发者困惑**：有些开发者习惯于使用Tab键，觉得四个空格缩进增加了敲代码的工作量。这些规约的制定初衷是为了提高代码的规范性、可读性和可维护性，但在实际应用中，某些规约可能会引起开发者的不适应，需要时间去理解和接受。强制使用Javadoc注释：
规约：类、类属性、类方法的注释必须使用Javadoc规范。
不太赞同或理解的原因：虽然Javadoc注释对于生成API文档非常有用，但在某些小型项目或快速迭代的项目中，开发者可能认为这些注释增加了编写和维护代码的负担。特别是在一些内部项目或工具类中，详细的Javadoc注释可能并不是必需的。
禁止使用System.out.println进行调试：
规约（假设存在）：禁止在生产代码中直接使用System.out.println进行调试。
不太赞同或理解的原因：虽然使用System.out.println进行调试不是最佳实践，特别是在生产环境中，但在某些快速定位问题或紧急修复的场景下，它可能是一种快速有效的方法。完全禁止这种做法可能会限制开发者的灵活性。
过度强调代码行数：
规约（非直接规约，但可能隐含在某些规约中）：代码行数越少越好。
不太赞同或理解的原因：代码行数并不是衡量代码质量的唯一标准。有时候，为了提高代码的可读性和可维护性，可能需要增加一些看似多余的代码（如注释、空行、变量命名等）。过度追求代码行数的减少可能会导致代码变得难以理解和维护。
禁止使用特定的设计模式：
规约（假设存在）：在某些情况下，禁止使用某些设计模式（如单例模式、观察者模式等）。
不太赞同或理解的原因：设计模式是软件工程中用于解决常见问题的最佳实践。禁止使用某些设计模式可能会限制开发者的设计选择，并导致代码难以适应不同的需求和场景。
对日志级别的严格规定：
规约：日志级别必须严格按照规定使用（如只使用INFO和ERROR级别）。
不太赞同或理解的原因：日志级别的选择应该根据具体的业务需求和场景来决定。过于严格的日志级别规定可能会导致重要信息的遗漏或冗余信息的过多。
禁止使用第三方库：
规约（假设存在）：项目中禁止使用任何第三方库。
不太赞同或理解的原因：第三方库为开发者提供了丰富的功能和工具，可以大大提高开发效率和质量。禁止使用第三方库可能会限制项目的功能和可扩展性。
对代码风格的过度追求：
规约（非直接规约，但可能隐含在某些规约中）：代码风格必须完全一致，包括空格、缩进、命名等。
不太赞同或理解的原因：虽然统一的代码风格有助于提升代码的可读性，但过度追求代码风格的一致性可能会忽略代码的实际功能和性能。此外，不同的开发者可能有自己的代码风格偏好，强制要求完全一致可能会引发不必要的争议。
对性能优化的过度要求：
规约（非直接规约，但可能隐含在某些规约中）：代码必须达到特定的性能指标。
不太赞同或理解的原因：性能优化是一个复杂的过程，需要根据具体的业务需求和场景来进行。过度要求代码达到特定的性能指标可能会导致开发者在性能优化上花费过多的时间和精力，而忽略了代码的其他方面（如可读性、可维护性等）。
需要注意的是，以上列出的规约及其原因可能因个人或团队的偏好而有所不同。在实际开发中，应根据项目的具体需求和团队的实际情况来制定合适的编程规范。同时，对于不太赞同或不太理解的规约，可以通过与团队成员讨论、寻求专家意见或参考其他权威资料来达成共识。