Tag Archives: code

How many times does this happen: you start a new iteration/sprint; you give estimates; you realize that the testing work will not be complete in the sprint for certain features?

While analyzing the work that needs to be done in a sprint you tend to think in a sequential manner: developers write the code –> only once the code is complete will the testing begin –> the developers are done with their work within the sprint, the testers are not. Strategies, workarounds and intense thought processing are used to determine how to somehow fit the testing work in the sprint, to not allow it to flow over into the next sprint. Is there an alternative? Yes.

Like this:

When i look at a test class, what i want to see is clean code. What i mean by that is, well a few things, but the most important one: i want the test class to hold the code for the tests, not the code for everything but the kitchen sink.

When we write tests we have a lot of data to prepare for them. Whether this is the ‘expected’ or the ‘actual’ data used in the tests, or some auxiliary code that we need, there always is some processing that needs to be done, apart from the actual asserts that a test should do. What the test class should contain is only the checking / asserting part, while having specialized classes generate all the data that is required in the test. A test class should only check the actual data against the expected data. This is the separation of concerns principle. Continue reading Write clean code for your tests by using the separation of concerns principle→

Start from the basic . When learning a new language, start from the beginning. Understand the elementary notions of it. Make sure you know what the language represents, what it is used for, how to write it properly. Read the tutorials, try out the examples.

Be lazy. Don’t reinvent the wheel. If you need some code that someone has already developed, use it. Use existing libraries where possible.

Modularize, don’t copy paste. When you know you have bits of code that will repeat themselves, extract them in a separate method and call that method wherever the code is needed.

Think and plan before you write your tests. Take time to analyze the requirements, to discuss the implementation with the developers, in order to identify the broadest and most relevant set of test cases. Take notes. Visualize how regular users will interact with the site. Make sketches. Jumping into testing just to finish it will make you skip some obvious scenarios.

Name things properly. Whenever you pick a name for a method, attribute or test scenario, make it relevant to what it is supposed to do. Describe it as much as possible. Use a decent amount of letters (not 2-3 and not 100).

Ask questions. Whenever something is not clear, or when you just need a confirmation of how well you understand the requirements, ask the people around you for information. No matter how basic or stupid the question might sound, it’s the start of a conversation which benefits all the people included in it.

Separate concerns. Don’t put all the code in one class. Analyze what you must write. What part is the setup, what part is the verification? Usually tests should largely focus on the actual testing, not the setup, so maybe extract that part into a separate class/unit, so that you minimize how large a test it. Also, you can put in all validations in a separate place. In this case, when you read the test, you should have – a line of code which calls the setup; the test logic; one line of code that performs the validation (if possible).

The What

I wrote a Java method, whose signature contains a number of parameters. This method is called by many other methods (i use the method in my tests). After a while i realize one of the parameters is not needed anymore. I want to change the method signature and to update all its’ references throughout my code.

Like this:

Some while ago i published an article in a local magazine on the topic of writing Selenium tests in an Object Oriented fashion. As i believe this is a very useful way of reducing the number of asserts tests can include, and to expand to a bigger audience, here is a different approach to writing Selenium tests.

Writing proper code in your IDE is made easier when using IntelliJ, due to its’ code analysis features. One option to perform a comprehensive coding issue search is to use the Inspect Code feature IntelliJ provides. From the class you want to check for issues, right click (inside the class, in the editor) and choose Analyze –> Inspect Code. Continue reading Improving your code by using IntelliJ’s Inspections feature→