Unit tests or the best project documentation.

A long time ago, when I was learning to use Java to do testing, I got help from a mysterious boss. We talked about unit testing, and the basic conclusion was that unit testing is probably useless.

As we all know, an obvious characteristic of automated testing compared with manual testing is that it takes a certain amount of time to produce more value than manual testing, which is still ideal. In some cases, it may never be. Unit testing is even worse, and judging from a group chat with big shots and braggadoons, good unit testing code is about 2-3 times as much as the code under test, which is unacceptable for developers. It is also widely accepted that unit testing is slower to work than automated testing, or even stops working before it does.

I’ve experimented with unit testing and written a bit about it:

  • Spock is configured in Maven and Gradle
  • Groovy unit testing framework Spock basic functionality Demo
  • Groovy unit testing framework Spock data driven Demo
  • Life is short? Try Groovy for unit testing
  • Better integration testing with WireMock
  • How do you test this approach – feature sections
  • How do you test this approach – the performance chapter
  • Unit test cases
  • JUnit 5 and Selenium Basics
  • JUnit 5 and Selenium Basics (ii)
  • JUnit 5 and Selenium Basics (3)

In recent days has been test framework to optimize the performance of before, in the process, before I use Groovy unit testing framework spock wrote two performance testing framework of unit cases has played a very big help, don’t have to check each class implementation code ever forget modify, run directly use cases, see the results. To share for your reference:

  • In between, I used Groovy’s ability to overload the multiplication operator for objects.
package com.FunTester.mockito.utils_test import com.fun.base.constaint.ThreadBase import com.fun.base.constaint.ThreadLimitTimesCount import com.fun.base.interfaces.MarkThread import com.fun.config.HttpClientConstant import com.fun.frame.SourceCode import com.fun.frame.excute.Concurrent import com.fun.frame.httpclient.FanLibrary import com.fun.frame.thead.HeaderMark import com.fun.frame.thead.RequestThreadTime import com.fun.frame.thead.RequestThreadTimes import org.apache.http.client.methods.HttpGet import org.slf4j.Logger import spock.lang.Shared import spock.lang.Specification import static com.fun.config.Constant.EMPTY import static com.fun.config.Constant.TEST_ERROR_CODE import static com.fun.frame.SourceCode.getLogger class PerformanceTest extends Specification {@shared Logger Logger = getLogger(this.getClass().getName()) def setupSpec() {Logger. ${logger.getName()}"} def setup() {logger.info" } def cleanup() {logger.info "Test method done!" } def cleanupSpec() {logger.info "test class finished! ${logger.getName()}"} def "() {given: HttpGet httpGet = FanLibrary.getHttpGet("https://cn.bing.com/"); MarkThread mark = new HeaderMark("requestid") FanLibrary.getHttpResponse(httpGet); HttpClientConstant.MAX_ACCEPT_TIME = -1 RequestThreadTimes threadTimes = new RequestThreadTimes(httpGet, 2, mark); new Concurrent(threadTimes * 2).start(); } def ""() {given: HttpGet HttpGet = fanlibrary.gethttpget ("https://cn.bing.com/"); MarkThread mark = new HeaderMark("requestid") FanLibrary.getHttpResponse(httpGet); HttpClientConstant.MAX_ACCEPT_TIME = -1 RequestThreadTime threadTimes = new RequestThreadTime(httpGet, 1, mark); new Concurrent(threadTimes * 2).start(); } def "test virtual class inner class implementation "() {given: def threads = [] 2.times { threads << new ThreadLimitTimesCount<Object>(null, 2, new MarkThread() { def i = SourceCode.getRandomInt(9) * 100 @Override String mark(ThreadBase threadBase) { return EMPTY + i++ } @Override MarkThread clone() { return null } }) { @Override protected void doing() throws Exception { sleep(200)  logger.info("test method over once .") } } } HttpClientConstant.MAX_ACCEPT_TIME = TEST_ERROR_CODE new Concurrent(threads).start() expect: 2 == 2 } }Copy the code

These are two use cases THAT I wrote during practice, and it’s hard to say how valuable they are, but when I found a way to quickly verify that the code works and the ability to debug quickly, I felt that they were both worthwhile.

These things, are adhere to will have effect.

  • Solemnly declare: the article was first published in the public number “FunTester”, prohibit third parties (except Tencent cloud) reprint, published.

Technical articles selected

  • Java one line of code to print a heart
  • Linux performance monitoring software Netdata Chinese version
  • Performance Testing Framework second edition
  • How to perform performance tests on a Linux command line interface
  • Graphic HTTP brain map
  • Automatically turn the Swagger document into test code
  • Probe into the Linear interface testing framework based on Java
  • Selenium 4.0 Alpha update log
  • Selenium 4.0 Alpha update practices
  • How to unify functional, automated, and performance test cases for interface testing

Selected non-technical articles

  • Why software testing as a career path?
  • Programming thinking for everyone
  • 7 Skills to become an automated test
  • How do YOU introduce automated testing in DevOps
  • Summary of Automatic Test failures on the Web
  • How do YOU introduce automated testing in DevOps
  • Testers often use excuses
  • API Testing Basics
  • API Automation Test Guide
  • Future QA test engineer