Many words are said about the merits of unit tests (TDD, BDD - in this case it does not matter), and also about why people do not use them anyway .



But I think that one of the main reasons is that people do not know where to start. Here I read an article about unit tests, I liked it; decided that we should ever try. But what next? Where to begin? How to invent all these requirements, how to call test methods?



Recently, the trend to turn unit tests into BDD specifications is gaining popularity, that is, it says that a good unit test should not test something, but describe the behavior of the program. But how to describe this damn behavior; where to take inspiration to come up with names for all these test cases?

')

This will be discussed:

Where to get inspiration

Once I came to an amazing discovery: this inspiration is everywhere, it surrounds us every day. There is no need to invent anything. It can simply be taken and used. This discovery seemed so important to me that I was in no hurry to share it with everyone.



So, my TOP-5 inspiration for writing unit tests.

5. Report to the head

Every morning at the meeting, the boss asks you: “What did you do yesterday?”.

- Bug corrected.

The boss doesn’t just believe the word and continues to dig:

- What kind of bug?

- Well, I fixed the validateReferenceNumber method.

- More specifically, what did you fix there?

- Well, earlier he crashed, if you give him an empty string at the input, and now he does not fall, but returns false.



Gotcha!



You see, an almost ready unit test is hanging in the air in front of your nose. After the meeting, sit at the computer and write:

public class ReferenceNumberTest { @Test public void emptyStringIsNotValidReferenceNumber() { assertFalse(validateReferenceNumber("")); } } 

Ideally, you should have done it yesterday, and then the boss could see which unit tests you added yesterday, and not torture you with your questions.

I am not joking, I know examples of very successful companies in which, instead of a Code Review, reviews of unit tests are done.

4. Explanations with colleagues

Every day a colleague comes to you and asks:

- Listen, I'm here, your debug-debug code, but I still can not understand how it works?

You patiently explain to him:

- Well, well, look: B comes here, and from here comes A.

- I still do not understand, but why A?

- Well, because for all letters that are smaller than I, this method should return the next letter.

- Aah, now I understand.



Gotcha again!



You yourself, without knowing it, have just formulated the name of the test case.

Mentally sending +1 to karma colleagues, they sat down and wrote:

 public class NanoTechnologySecurityTest { @Test public void shouldReturnNextLetterForAllLettersExceptJa() { assertEquals("", encodeLetter("")); } } 

3. Conversation with the client

On any beautiful day, a customer can call and say:

- Remember, we discussed that all fields on the form should be validated automatically as soon as the field loses focus? So, I changed my mind. I showed the beta to my grandmother, and she said that it was not clear, and in general ajax sucks . Let the fields be validated only when the client clicks the “Submit” button .



And again Gotcha!



The client has just formulated the text of the test case for us.



Mentally sending -10 to the client’s karma, we sat down and wrote ... UI tests, of course, are a bit more complicated than regular unit tests, but it could look something like this:

 public class TimotiFanClubRegistrationFormTest { @Test public void shouldValidateFieldsOnFormSubmission() { Form form = new Form(); assertTrue(form.isValid()); form.submit(); assertFalse(form.isSubmitted()); assertFalse(form.isValid()); form.setName("Baba Njura"); form.setEmail("Baba.Njura@yandex.ru"); form.submit(); assertTrue(form.isSubmitted()); } } 

2. Bug

Every day you go to Jira (and who are really lucky - to Pivotal Tracker ) and find out that malicious testers found a bug in your program. If you are lucky with the tester, then the description of the bugs sounds like this: “If you enter the wrong password three times, the account should be blocked, but I will not be blocked. I have already introduced fifteen times. ”



Mentally saying thanks to the tester (that's enough of him and thanks, you still can't save his karma), we sit down and write:

 public class LoginPageTest { @Test public void shouldBlockAccountAfter3UnsuccessfulTries() { LoginPage page = new LoginPage(); page.login("vasjok47", "Toiota"); page.login("vasjok47", "Tojota"); page.login("vasjok47", "tayota"); assertTrue(AccountDAO.getAccount("vasjok47).isBlocked()); } } 

There is even a separate term for this: Bug driven development . I myself do not favor this approach, since unit tests (they are the specification) should still be written BEFORE the code (the basic principle of TDD), but as a source of inspiration, the bug tracker is quite suitable.

1. Commit message (how is it in Russian?)

This is my favorite item, I would like to dwell on it.



When you change the code, there is usually a reason for it. The reason usually lies in the fact that you want this code to do something differently (we exclude refactoring, performance improvements and placing parentheses in feng shui).



Suppose we had a code that validated an email. In particular, he checked that at the end of the email there must be a dot and two characters. And even for him there is a unit test, just like people. And then suddenly it turns out that after the point there may be more letters, for example, some email clients end with ".info". Said and done, the code was fixed, and even one line was added to the existing unit test:

 public class EmailValidatorTest { @Test public void testValidateEmail() { assertTrue(validateEmail("timati@rambler.ru")); ... assertTrue(validateEmail("tina.turner@music.info")); // 4 letters now allowed! } } 

And now we want to commit this business to CVS (and those lucky are those in SVN, and who are lucky in general, those in GIT ).

For a commit, you need to write an explanation (commit message) in which you usually write, and what has changed in the code. And here you are:

 svn commit -m "       ." 

And this is the real Gotcha!



This is what we need. Do not press enter yet.

We stopped, selected this text with the mouse. Opened the unit test class. They wrote Test , pasted the copied text and translated it into English. You can clarify a little or summarize to taste.

 public class EmailValidatorTest { @Test public void validEmailShouldEndWithDotFollowedBySeveralLetters() { assertTrue(validateEmail("timati@rambler.ru")); ... assertTrue(validateEmail("tina.turner@music.info")); } } 

Now you can safely commit and mentally send +1 to your karma. Today we were able to materialize some knowledge from the air into something more tangible. Now this knowledge will not disappear anywhere and will be automatically checked at each assembly of the project.



Well, is not it so good, huh?