Golang's test was a little weird.

Recently in the study Go . Then I can't help but wonder why some of the small partners ' Go test readability can be so strange (cha). A good test is a document? What about the test boundary? What's the deal Given When Then ? Is it my skill?

I have always believed that programming ideas or methodologies belong to the knowledge that can be migrated, regardless of the language in which the body. But after reading some Go of the test chestnuts, I began to panic ~

Ideals and realities

Don't believe me? Crossing please see:

Because the test case is too long, it cannot be truncated. Yes, too long, a screen can not fit. Curious of you, please poke->>> poke me

I do not know how you taste, anyway, I have a bit bitter taste.

Such chestnuts, in the awesome-go list of open-source libraries, are still many. No, no, can't be brought crooked (Ps:github is indeed the world's largest community of friends, easy to bring crooked people, hahaha).

In one line: multi-product neat, simple code, help protect the hairline.

Of course, "a stick to kill the boat people," to have found the eyes of beauty. Crossing please see:

It was written by the Great God TJ Holowaychuk , and it was remarkable. Curious of you, please poke->>> poke me

Dream of landing

What conditions to meet the test, is worth the taste? I think, the first is, the 可读性 second or 可读性 the third or 可读性 .

Often heard that the test is a document , then the question came, good read the document, long what kind? When I was in elementary school, the teacher taught me to write a composition, clear structure, and highlight the central idea!!!

Writing the test code is the same, to write her (computer) can understand the "article", but also to write the "article" we can product. Then, the BDD test of landing mode is undoubtedly a good choice.

Crossing please see:

The central idea is prominent and the structure is clear. The first describes the main functions, and then treats the descriptions separately according to the different use case scenarios.

Chestnuts on the ground:

There is wood that looks very comfortable!!! Are you thinking about testing the implementation code? Crossing you continue to see:

Full chestnuts, curious of you, poke->>> poke at me

Above the chestnut, landing is the test three-stage, GIVE-WHEN-THEN :

• Given: Set up context for a behaviour
• When : specify some action
• Then : Specify some outcome

Action + Outcome = Behaviour, behavior is at the heart of testing attention. Given, the preparation of the test case business scenario consists primarily of preparing business data ,mocking external dependencies , and preparing user information . As the business becomes more complex, the preparation of test contexts becomes more complex and the process of preparing business data becomes more and more time consuming. For a chestnut, for API testing, the relative need to spend time writing is Given the process. Then, mainly write the assertion, Assert API The return data, the When trigger action, is simply to send a request, call API .

In an interrupt: How to solve Given the problem of writing time-consuming, to DSL Fixture understand.

Written in the last

Coffee finished, and then I do not know how to write, donuts it, because the back of me will not ah ...

original link