Asier's thoughts

Blogging about software development


Leave a comment

This site has been migrated

I just migrated this blog to asierba.github.io.

I also changed the dns entry of asierba.net to point there, so you shouldn’t be able to get to this blog through asierba.net. If you are, let me know please.

If you are seeing this post as part of your rss reader that means you are subscribed to the wrong rss feed. Please update it: asierba.net/feed

I won’t be posting any more here (asierba.wordpress.com), so expect this site to die.

 

More info about the migration here: http://asierba.net/2017/02/23/from-wordpress-to-jekyll/

 


Leave a comment

Judge the code, not the developer

I’ve been paying attention recently to conversations we have at work. I can hear people complaining about the code, how bad it is, not readable, difficult to make changes.. They will refer to the people who wrote it. And I do it too! Even if we don’t know who wrote it. It doesn’t matter, is ‘us’ and ‘then’.

  • They wrote this crazy stuff.. why??”
  • somebody had this idea of creating this hierarchy of classes. Look now, how can we extended this class without affecting this other??”
  • “look, a developer added an extra call to the service here. This is making our application not to perform well.”

We are judging the people, instead of the code. This just creates tension between co-workers. It creates a difference between the person who wrote the ugly code and us. We are kind of saying they don’t know how to write code, do they job properly.. ultimately we are just saying they are inferior and that we are better than them. We judge them.

We can just change our aptitude if we detach the code from the people.

  • “this crazy stuff.. why??”
  • “this hierarchy of classes. Look now, how can we extended this class without affecting this other??”
  • “look, there is an extra call to the service here. This is making our application not to perform well.”

We would still be stating the same thing: the code is bad, not readable, difficult to make changes.. BUT we won’t be judging people, our co-workers, our team mates. We will be all in the same boat seeing the same problems and ultimately fixing them together.


2 Comments

Implicit vs Explicit Waits in selenium

The last few days at work we have been fixing some intermittently failing tests in selenium. In the process I came to learn the difference between implicit and explicit waits.

The needs of waits.
When running a test against an application UI sometimes you need to wait for an element to be present. This could be due to the whole interface taking time to fully load or just a small part of it.

When we jumped to fix these tests we saw that they were doing what they mean-to and that the application was really doing what the tests said, but the problem was down to page or elements or the page loading slower that expected. Waits would be our allies in our battle.

Two types of waits
There are two type of waits you can use in Selenium: implicit and explicit waits.

  • Implicit waits are defined for the whole test suite.
    Every time the selenium driver tries to find an element on a page it will wait a certain amount of time before throwing an element not found error.
    By default the implicit wait is 0, this means the driver won’t wait at all.
    This is how you define the implicit wait of 3 seconds:

    Driver.Manage().Timeouts()
    .ImplicitlyWait(TimeSpan.FromSeconds(3));

    Each time the driver looks for an element (i.e using Driver.FindElement(..)) it will wait 3 seconds before failing. If it finds it before it will continue with the test run.

  • Explicit waits are defined just for a single purpose.
    For example we could wait for a progress bar to finish, a pop up to hide or an element to render.
    This is how you define an explicit wait for the body element of 5 seconds:

    var wait = new WebDriverWait(Driver, TimeSpan.FromSeconds(5));
    wait.Until(d => d.FindElement(By.TagName("body")));

    If the driver doesn’t find the html “body” element in the page within 5 seconds it will throw an exception. If it finds it before it will continue with the test run.

For both cases the driver will constantly check for UI changes. If the the element is present before the time it will continue, it won’t keep waiting.

Favour explicit over implicit waits
By rule of thumbs you should favour explicit waits over implicit. If your tests is failing because certain element takes time to load add a explicit wait for that element. You could also fix the problem adding an implicit wait, but that would affect the whole test suite and make tests slower and you wouldn’t be addressing the underlying problem.
In the other hand, sometimes the whole website could be slow and pages would always take a few seconds to load. In those cases it’s ok to add implicit waits, but I wouldn’t recommend any more than 2-3 seconds.

[+] info:


Leave a comment

Need to blog more

It’s been a while since I don’t write a blogpost. I should be doing it more often.

I could mention various excuses, but the only true is that I’ve been a bit lazy..

Writing a blogpost requires a lot of time and thinking from me. Or that’s at least the idea I have in my head. I try to write long blogposts with amazing topic. Then I see the results and I am not happy with them.

The problem is that… I suck at it! Yes, I am not good at it. Yet.

I need a change.

It’s well known, practice make the master. So what’s the best way to improve? Write more and more and more!

So from now on I will post frequent little blogposts. I will make them short so the task is less daunting for me and hopefully more enjoyable for you 🙂


Leave a comment

Avoid Code Freezes

Early and Often

A project manager recently told me that he wanted to implement a code freeze prior to user acceptance testing.  This request struck me as odd since I don’t recall having implemented a code freeze on a project in years.  My immediate response was that we do not need a code freeze.  All checked in code is tested for its production readiness via a deployment pipeline.

The intent of a code freeze is to identify and lock down a known “good” state of the source code.  The code can then be built, and then deployed from this known “good” state.  If a developer checks in a change after a code freeze, then this known “good” state can be considered tainted.   The intent behind implementing a code freeze is well placed, but the execution slows down a team’s progress.

The need to implement a code freeze demonstrates a lack of understanding…

View original post 143 more words


Leave a comment

Hello world!

Hi dear reader,

This is my first post of my blog about software development. The idea is to write some stuff with the aim of learning from it. Because the best way of learning is teaching to others! 🙂

As Albert Einsten said once:

You do not really understand something unless you can explain it to your grandmother.

We will see how it goes..