Forem: Lucas Andrade

Building an Image Gallery with Pure JavaScript

Lucas Andrade — Thu, 16 Mar 2023 20:27:39 +0000

Hello there! 👋

I'm Lucas, a Brazilian engineer, and this is Yet Another DEV Content nobody asked for (but I made it anyway 😂). My goal with this blog is to talk about things related to the software development world and document personal projects I've worked on, while also honing recently acquired knowledge by sharing it. If you like it, follow me for more posts like this one!

Today we'll tackle a small JavaScript project called Image Gallery featured in one of MDN's JavaScript tutorials.

Please note that this is my solution to this challenge and probably not the best one you will find out there. Also note that the code is shown in this article in a manner that not always represent the final files. If you want to check the final code, a link to the Github repository as well as a link to the deployed app are provided in the Reference section at the end of the article.

The GIF below shows how the project should look like when we're finished. Let's build it!

👣 Step-by-step Breakdown

The MDN tutorial provides initial boilerplate code for this project and all five images that we're going to use.

We won't get into details on how the HTML was structured nor how it was styled since the goal here is to focus on the JavaScript part.

If you open the boilerplate index.html file, this is how it initially looks like:

You can immediately notice that the thumbnail images are missing and the button has no functionality for now. So here's what we're going to do step-by-step:

Declare array of image filenames and append them to the DOM (inside the thumb bar);
Add a click event handler to each thumbnail image;
Add a click event handler to the Darken/Lighten button.

1️⃣ Adding the thumbnail images to the DOM

We can do it by first declaring a constant array to hold the image filenames for us. This is a viable alternative because we know the number of images is low and static (five).

Then it is time to declare an object with an alt description for each image. This step is extra important to improve the accessibility of our app and is often overlooked. I chose to use the filenames as keys, so its easier to retrieve the value we want in the next steps.

We'll also need to store a reference to the thumb bar div HTML element, so we can append the images to it next. Fortunately this has been provided in the boilerplate code already as the thumbBar constant.

/** 
  File: "~/main.js"
  Showing: Only code related to step 1
*/

const thumbBar = document.querySelector('.thumb-bar');

/* Declaring the array of image filenames */
const imageFilenames = [
  'pic1.jpg',
  'pic2.jpg',
  'pic3.jpg',
  'pic4.jpg',
  'pic5.jpg',
];

/* Declaring the alternative text for each image file */
const altTexts = {
  'pic1.jpg': 'A closeup of an human eye',
  'pic2.jpg': 'An abstract pattern painting',
  'pic3.jpg': 'A lot of violet and white flowers',
  'pic4.jpg': 'An Egyptian painting in a wall',
  'pic5.jpg': 'A yellow butterfly in a leaf',
};

Next, we'll loop through the array with the forEach method so we can append the images. The image elements will be created inside each iteration of the loop, the needed HTML attributes will be added and finally the element will be appended as a child of the thumb bar container div.

/** 
  File: "~/main.js"
  Showing: Only code related to step 1
*/

/* Looping through images */
imageFilenames.forEach((imageName) => {
  const newImage = document.createElement('img');
  newImage.setAttribute('src', `images/${imageName}`);
  newImage.setAttribute('alt', altTexts[imageName]);
  thumbBar.appendChild(newImage);
});

With this we've finished the first step. Again, we won't dive into how it was styled. This is how it should like now:

2️⃣ Add a click event handler to each thumbnail image

What we want to achieve next is to change the displayed image (the bigger one) whenever the user clicks any of the thumbnail images that we added. In order to achieve that, we will need reference to the displayed image element just like we did for the thumb bar container, but it was also already declared in the boilerplate code.

Let's create a function to handle the click event on the images. Any function passed as a callback to the addEventListener() method will automatically pass the event as an argument. The Event object has a target property that holds a reference to the HTML element that triggered the event. We will use the target element so we can know the new src and alt attributes of the clicked image, and change the attributes of the displayed image to equals the target image.

/** 
  File: "~/main.js"
  Showing: Only code related to step 2
*/

function handleImageClick({ target }) {
  displayedImage.setAttribute('src', target.getAttribute('src'));
  displayedImage.setAttribute('alt', target.getAttribute('alt'));
}

const displayedImage = document.querySelector('.displayed-img');

/* Looping through images */
imageFilenames.forEach((imageName) => {
  const newImage = document.createElement('img');
  newImage.setAttribute('src', `images/${imageName}`);
  newImage.setAttribute('alt', altTexts[imageName]);
  thumbBar.appendChild(newImage);
  img.addEventListener('click', handleImageClick);
});

With this we have successfully achieved step 2 and are only missing the last part!

3️⃣ Add a click event handler to the Darken/Lighten button

To achieve what we want in the third and last step let's create a function to handle the click event on the button. This function should read the class name value of the button and take one of two actions depending on the result.

If the class is "dark", it means the user clicked the Darken button. When this happens the text content of the button should change to "Lighten", the overlay div background opacity should change to "0.5" and finally the class name should change to "light" so the action changes when the next click happens.

Else it means the class is "light". In this case the button text content should change to "Lighten", the overlay div opacity should change to "0" so it becomes invisible again and finally the class name should change to "dark" so the action changes when the next click happens.

/** 
  File: "~/main.js"
  Showing: Only code related to step 3
*/

/* Wiring up the Darken/Lighten button */
function handleButtonClick() {
  let currentClass = btn.getAttribute('class');
  if (currentClass === 'dark') {
    btn.textContent = 'Lighten';
    overlay.style.backgroundColor = 'rgba(0,0,0,0.5)';
    btn.setAttribute('class', 'light');
  } else {
    btn.textContent = 'Darken';
    overlay.style.backgroundColor = 'rgba(0,0,0,0)';
    btn.setAttribute('class', 'dark');
  }
}

btn.addEventListener('click', handleButtonClick);

We're done! This is how the button functionality should look like now:

If you've read this far, I hope the content has added something for you. If it didn't, remember: This is just another ordinary DEV content 😬.

🍀 See ya!

🔍 References

Image gallery - Learn web development | MDN
Image gallery finished example
Github repository with the final code
Final app deployed on Github Actions

😁 Let's chat!

Github
Linkedin

Lucas AndradeFollow

I'm a Brazilian QA Engineer. passionate about automation.

Selenium 4 Looks Pretty

Lucas Andrade — Sun, 31 Oct 2021 17:22:05 +0000

Hello there! 👋

I'm Lucas, a Brazilian QA engineer, and this is Another QA Content nobody asked for (but i made it anyway 😂). My goal with this blog is to talk about things related to the QA world in my own way, giving my opinion and point of view. If you like it, follow me for more posts like this one!

Selenium 4 is finally officially released! And I've been playing with some of the new features. In this post, I'll show you in practice some cool new things you can do with Selenium now.

I won't be focusing on good practices, like using hooks or not setting long explicit waits. The main goal here is to test out some new stuff. I'll show code snippets to summarize, but you can find a link to the Github repo at the end of this post if you want to check out the full code.

😃 Relative Locators are here

Remember Taiko's Proximity Selectors? Selenium now has its own similar feature called Relative Locators. It works similarly, you can find web elements that are above, below, toRightOf, toLeftOF or even near a fixed reference element.

And it's simple to use. All you have to do is import the with class. Use with to encapsulate the By object and then, you'll be able to chain a relative selector.

For this example, we'll be using BlazeDemo (a sample travel agency website). Let's try to perform a simple click at the button "Find Flights" without creating a specific selector/xpath for it.

To achieve our goal, let's use the destination city select as reference. Inspecting it, we can see that one option to retrieve it is by its "name" attribute.

Let's implement a simple test then. We'll select "Dublin" as the destination city and then assert that the available flights page title is displayed correctly.

/**
* File: AppTest.java
*/

class AppTest {

    @Test
    void relativeSelector(){
        // 1. Configuration steps;
        String expectedTitle = "Flights from Paris to Dublin:";
        System.setProperty("webdriver.chrome.driver", "c:/chromedriver.exe");
        WebDriver driver = new ChromeDriver();
        driver.manage().window().maximize();
        driver.get("https://blazedemo.com/");
        // 2. Retrieve the select "Destination city" and select option 'Dublin';
        WebElement toDestination = driver.findElement(By.cssSelector("[name='toPort']"));
        Select selectElement = new Select(toDestination);
        selectElement.selectByVisibleText("Dublin");
        // 3. Use Relative Locator 'below' to retrieve the "Find Flights" button;
        WebElement findFlightsButton = driver.findElement(with(By.tagName("input")).below(toDestination));
        findFlightsButton.click();
        // 4. Assert that the button was clicked by validating page title.
        String actualTitle = driver.findElement(By.tagName("h3")).getText();
        Assertions.assertEquals(expectedTitle, actualTitle);
        driver.quit();
    }
}

I've added a sleep to the code snippet above so that we can see the test in action!

This is useful when you don't have access to the source code (to add an 'id' or 'test-id' in the HTML) and want to avoid writing a complex xpath.

🤯 Support for Chrome DevTools Protocol

The Chrome DevTools Protocol (CDP) is a protocol to communicate with Chromium-based browser internal configurations. Tools can build an API around it to allow a low-level browser configuration (e.g. instrument, inspect, debug and profile). If you're interested in learning more about what you can do with it, visit CDP Github.io page.

Selenium 4 brings its own API to communicate with CDP. Now its possible to do a lot of advanced browser configurations for your tests, like changing the client's geolocation for example.

We can implement a sample test for the above situation using the page gps-coordinates/my-location. It has a feature that show user's location coordinates and address based on the geolocation. We'll implement a test that simply asserts that the location shown is the location we set. See an example below:

Since I need some vacation, let's teleport ourselves to Cancún/Mexico using code! I've already googled the latitude and longitude values for us, so let's jump to the part where i show you the code:

/**
* File: AppTest.java
*/

class AppTest {

    @Test
    void setGeolocation throws InterruptedException(){
        // 1. Configuration Steps
        String expectedAddress = "Calle 50 Poniente, 77510 Cancun, ROO, Mexico";
        System.setProperty("webdriver.chrome.driver", "c:/chromedriver.exe");
        WebDriver driver = new ChromeDriver();
        driver.manage().window().maximize();
        // 2. Create map with arguments for "Emulate.setGeolocationOverride"
        Map<String, Object> coordinatesMap = new HashMap<String, Object>();
        coordinatesMap.put("latitude", 21.17429);
        coordinatesMap.put("longitude", -86.84656);
        coordinatesMap.put("accuracy", 1);
        // 3. Calls CDP's "Emulation.setGeolocationOverride" to set new geolocation
        ((ChromeDriver)driver).executeCdpCommand("Emulation.setGeolocationOverride", coordinatesMap);
        driver.get("https://www.gps-coordinates.net/my-location");
        Thread.sleep(3000);
        // 4. Asserts that the Address shown is Cancún/Mexico
        String actualAddress = driver.findElement(By.id("addr")).getText();
        Assertions.assertEquals(expectedAddress, actualAddress);
        driver.quit();
    }
}

And it's time to see our second test running!

We've just teleported! Of course, you'll have to believe that i'm not writing this from Cancún 😂. But you'll have to agree with me, this new feature (calling CDP commands) is really powerful. This geolocation change allow us to test features like "Find the nearest store" for example.

This is it for today. Have you learned some other new stuff on Selenium 4 already? Share with me in the comments!

If you've read this far, I hope the content has added something for you. If it didn't, remember: This is just another ordinary QA content 😬.

🍀 See ya!

Lucas AndradeFollow

I'm a Brazilian QA Engineer. passionate about automation.

Grey Box Testing

Lucas Andrade — Sat, 23 Oct 2021 03:06:11 +0000

Hello there! 👋

The CTFL syllabus (2018) covers White-box and Black-box testing, but it doesn't mention a single word about Grey-box testing. Nor the book The art of software testing (3rd edition). What is it? Is it really not worth the mention? Let's find out.

🧩A brief about Black-box and White-box testing techniques

To understand what Grey-box testing is, we first must know what Black-box and White-box testing are.

⬛ Black-box testing (a.k.a. Closed-box testing) is a set of techniques in which the tester test a software's functionality without the need to know how it has been built. In other words, the tester checks whether determined inputs will produce desired outputs. Some examples of Black-box techniques are: Equivalence Partitioning, Boundary Value and Cause-Effect Graph.
⬜ White-box testing (a.k.a. Open-box testing) at the other hand, is a technique in which internal structure of the software is known by the tester. This way he can verify the code flow (conditionals, loops, etc.), security holes and other things. Some examples of White-box techniques are: Statement Coverage and Decision Coverage.

👩‍🏫 The definition of Grey-box testing can be confuse

Ok, now its easier to define what Grey-box testing is! If you access any page listed at the references section you'll find this definition: Grey-box testing is a technique in which the tester has PARTIAL knowledge of the source code. It's like it fits somewhere in the middle of White-box and Black-box testing, or even a sum of the two previous. Some example of Grey-box testing techniques are: Matrix Testing, Orthonogal Array Testing and Pattern Testing.

Have you seen the problem yet? I'll tell you: How much knowledge is considered partial?

Let's consider some options for answering the question above:

You have access to just a part of the code;
You have access to the code, but you can't understand it fully.

How would you define Grey-box testing then?

😯 How much dev knowledge should i have as QA

Let's say you, as a QA engineer, are testing a web application and you have access to the source code. Hence, you're able to apply White-box testing techniques, right? Not exactly.

As a QA, you're not expected to deeply know the programming languages and frameworks used to build the application (or at least you shouldn't). This is a job for your fellow comrades developers. Therefore, White-box testing techniques seems to be a lot more useful for designing unit/component tests.

Of course, that doesn't mean a QA can't have some front-end or back-end development knowledge and apply White-box techniques to help the team to improve testing coverage. But knowing how conditionals and loops work may not be sufficient in some cases. That's why the most common scenario is: Devs design and automate unit/integration tests and QAs design and automate end-to-end/API tests (there are more tests a QA can perform but more of that in later posts).

And Black-box testing techniques consists mostly on detecting the best test data (inputs) for minimizing the amount of tests cases needed. It seems like a perfect fit for QAs, right? And it is! No wonder it's a high demanded skill when applying for a QA role.

💭 What i concluded about Grey-box testing

After doing some research, i've found out that Grey-box testing techniques are much like Black-box testing techniques and are best suited for QAs in general. But the tests are performed by a QA that has some knowledge of how applications are made.

Consider the following example from Thomas Hamilton at Guru99's Grey-Box testing page (You can find the whole article at the references section):

While testing websites feature like links or orphan links, if tester encounters any problem with these links, then he can make the changes straightaway in HTML code and can check in real time.

In another words. If a tester is accustumed to perform Black-box testing, he would just open a bug for developers to fix saying that the link is broken. In this case, a QA applying a Grey-box technique could open the browser devtools and check the HTML structure to see if the href attribute is set correctly on the anchor tag, providing a more detailed bug report.

The same can happen for example if some requisiton fails with a 4xx or 5xx status. Opening devtools network tab and observing things like the requisiton header or response can lead to a detail-rich bug report, helping developers to debug the problem easily.

There's even a Grey-box technique in which the variables of the software are examined and assessed according to the risks it presents (Matrix Testing).

And just for the mention, it's possible to implement Grey-box testing as a form of penetration testing (Pentest) too.

My conclusion is that combining Black-box and Grey-box testing techniques is the way to go for modern software testers/QA engineers. It has some cool benefits like making your teammates appreciate working with you 😉.

How about you? Do you have a different point of view? Share with me in the comments.

If you've read this far, i hope the content has added something for you. If it didn't, remember: This is just another ordinary QA content 😬.

🍀 See ya!

🔍 References

CTFL Syllabus 2018
Thomas Hamilton at Guru99
Imperva
Software Testing Help

😁 Let's chat!

Github
Linkedin

The 7 Software Testing Principles

Lucas Andrade — Sun, 10 Oct 2021 21:19:41 +0000

Hello there! 👋

Today i want to talk about a subject that is covered at the first chapter of the CTFL syllabus. The seven ~~commandments~~ principles of software testing. (This was a Moses pun if you didn't get it). No more puns ~~for now~~, let's open this ocean of knowlegde!

1️⃣ Testing shows the presence of defects, not their absence

Many QA engineers may have been in a situation like the following before: The product owner or even the client says your job is to guarantee the sprint deliverable is bug free.

Testing is a destructive activity, it's goal is to make the software fail. When a tester write a test case, it is meant to find a bug, not to prove there is none.

So, this principle states that it's impossible to guarantee that a testing object is defect free.

Some points to be aware: Maybe a non-QA person will misunderstood this principle as an excuse for a QA that isn't good at his job. And on the other hand, it can be misused by a QA to justify not catching a bug that should have been found easily. I personally think this principle isn't meant to justify a bug that has got into production, i think it's meant to avoid creating false expectation on the product and the QA job.

2️⃣ Exhaustive testing is impossible

As a QA, you will probably never have the time to test every possible scenario of a software.

Imagine a small form with 3 select fields, every field has 10 options. To test every possible scenario, it would take you 10³ = 1000 test cases.

We can use a black box testing technique called equivalent partitioning. Briefly explaining, it consists of dividing test data into partitions in such a way that all the members of a given partition are expected to be processed in the same way.

There can even be a situation in wich time is a concern. In this case it's more recomended to perform a risk analysis, and prioritize tests based on the higher risks for the business.

3️⃣ Early testing saves time and money

This principle is probably the parent of the trending shift-left testing approach. It states that the testing activities should start as soon as possible in a project.

Testing activities are not limited to execute or automate E2E tests when a feature is ready. A tester can also review documentation and requisits, to prevent errors and mistakes from advancing to later stages of the software development life cycle. Remember, the later you find a problem, the more it will cost to fix.

4️⃣ Defects cluster together

This principle is an application of the Pareto Principle. Maybe you don't know it by its name, but you might have heard about it somewhere. Here is a brief about it:

For many outcomes, roughly 80% of consequences come from 20% of causes

In software testing, there's a high probability that 80% of the problems can be found at 20% of the modules/components. So be aware when you find a bug, for there can be more, hiding on the same feature.

5️⃣ Beware of the pesticide paradox

To explain this one i'll borrow a paragraph from a Guru99 article about the 7 principles of testing (you can find the link bellow in the references section).

Repetitive use of the same pesticide mix to eradicate insects during farming will over time lead to the insects developing resistance to the pesticide.

So, if you repeat the same test case again and again, chances are it will become less effective (consider an effective test case one that has a higher probability of finding bugs). Because of that, as a QA you need to review your testing techniques and test cases frequently. In an Agile project where requisits change very often, this is even more crucial.

6️⃣ Testing is context dependent

This principle talks about how different contexts may influence the test in different ways.

Testing in an agile project is done differently than it's done in waterfall, due to the differences in release periodicity.

Testing an e-commerce is done differently than testing an internet banking system, due to the different risks involved.

The correct tool for automating regression tests depends heavily on the context too. As you get more experienced, the more you get to understand the context you're incerted, and plan your QA job to fit it well.

7️⃣ Absence-of-errors is a falacy

Like we have seen in principle number 2, testing shows the presence of defects and not their absence. What this principle states is that no matter how much effort you or your team put on testing activities, the tests alone can never guarantee an error-free software.

A software isn't considered to have an error only when something doesn't work as expected. A system that is overcomplicated for the user (bad usability) or doesn't fullfil the user needs (bad modeling) is also considered to have errors.

💰Bonus

To test your understanding of the seven testing principles presented above, try to solve this question from the CTFL 2018 sample exam:

🤔(Sample Exam C, Question 4): A product owner says that your role as a tester on an Agile team is to catch all the bugs before the end of each iteration. Which of the following is a testing principle that could be used to respond to this (false) statement?

a) Defect clustering
b) Testing shows the presence of defects
c) Absence of error fallacy
d) Root cause analysis

The answer is below.

If you've read this far, i hope the content has added something for you. If it didn't, remember: This is just another ordinary QA content 😬.

🍀 See ya!

❗ Bonus question answer

b is correct. Testing can show the presence of defects but cannot prove their absence, which makes it impossible to know if you have caught all the bugs. Further, the impossibility of exhaustive testing makes it impossible for you to catch all the bugs

🔍 References

CTFL Syllabus 2018
Guru99
Geek for Geeks

😁 Let's chat!

Github
Linkedin

Taiko's Proximity Selectors

Lucas Andrade — Sat, 22 May 2021 00:50:44 +0000

Hello there! 👋

Recently i've worked on a User Interface (UI) testing project, where me and my team were using Node.js, Gauge and Taiko as tools for automation. Before i've been a part of this team, i knew some JavaScript test frameworks and libraries, but i had never heard of Taiko. This can be your case, so in this article i'll show you the basic concepts of Taiko and how it can be a great choice for your next automated UI tests project.

🔨Installing Taiko

Taiko is a node module developed by ThoughtWorks. It allows us to interact with Chrome and Chromium browsers using proximity selectors to easilly find web elements on a page.

The simplest way to try out Taiko is using its Read-eval-print-loop (REPL). For that you will need to have Node.js installed on your machine. Open your favorite terminal emulator and run:

npm install -g taiko

I'll not dive deeply into how to set up a full automation project in this post. So, if this is what you're looking for, i recomend you read about Gauge.

If the installation was a success, the REPL shall open when you type "taiko" in your terminal. Like shown below:

👉Using a proximity selector

To demonstrate how easy it is to interact with web elements on a page using Taiko's proximity selectors, i'll be using the Automation Practice e-commerce. You can navigate to the page by running the following commands (I'll explain each one later):

taiko
openBrowser()
goto("http://automationpractice.com")

At the home page, we can see a situation where Taiko can show its potential. In this case, the page contains two products with exactly the same name.

Using the proximity selectors, it's not necessary to inspect the page looking for a unique identifier for the product you want to perform a click on. In other words, you ain't gonna need a CSS selector or an XPath here.

Let's supose you want to click at the second "Printed Dress" product, the one whose price is "$50.99". In this case you can tell Taiko to click at the "Printed Dress" that is localized above the "$50.99" text. Like shown in the image below:

Explaining in details what happened:

//Open Taiko's REPL;
taiko
// Open the automation controlled Browser, Chromium by default;
openBrowser() 
// Navigates to the URL passed as a parameter;
goto("https://automationpractice.com")
/*
Perform a click action. Receive two arguments:
    1st: The element you want to click. 
    Could be a "link" or an "image" for example. 
    If not informed, the default is "text";
    2nd: A proximity selector to help Taiko finding the 
    element. 
    We want the text element that is above another text element 
    "$59.99".
*/
click("Printed Dress", above("$50.99"))

Cool right? Taiko currently have these other proximity selectors besides above: below, toLeftOf, toRightOf, near and within.

Of course there is no such thing as an "ultimate automation tool", maybe they won't help you in a more complex situation. But worry not, cause Taiko's API also have methods for locating elements using the old fashion like using the element html attribute "id". You can even combine the two of them! For more on that, refer to Taiko's Documentation.

Besides that team i've worked on, to this day i still haven't found another QA Engineers or Developers that use Taiko to automate tests at their jobs. Maybe you can be next after reading this post.

If you've read this far, i hope the content has added something for you. If it didn't, remember: This is just another ordinary QA content 😬.

🍀 See ya!

🤝 Thanks

Thanks to my fellow teammates at everis for all the knowledge we shared during those months working together
Samuca, Ronaldo, Andrei, Felipe and Duda.

🔍 References

Taiko's Webpage
Taiko's Github Repository

😁 Let's chat!

Github
Linkedin

Forem: Lucas Andrade

Building an Image Gallery with Pure JavaScript

👣 Step-by-step Breakdown

1️⃣ Adding the thumbnail images to the DOM

2️⃣ Add a click event handler to each thumbnail image

3️⃣ Add a click event handler to the Darken/Lighten button

🔍 References

😁 Let's chat!

Lucas AndradeFollow

Selenium 4 Looks Pretty

😃 Relative Locators are here

🤯 Support for Chrome DevTools Protocol

👩‍💻 Full Code

🔍 References

😁 Let's chat!

Lucas AndradeFollow

Grey Box Testing

🧩A brief about Black-box and White-box testing techniques

👩‍🏫 The definition of Grey-box testing can be confuse

😯 How much dev knowledge should i have as QA

💭 What i concluded about Grey-box testing

🔍 References

😁 Let's chat!

The 7 Software Testing Principles

1️⃣ Testing shows the presence of defects, not their absence

2️⃣ Exhaustive testing is impossible

3️⃣ Early testing saves time and money

4️⃣ Defects cluster together

5️⃣ Beware of the pesticide paradox

6️⃣ Testing is context dependent

7️⃣ Absence-of-errors is a falacy

💰Bonus

❗ Bonus question answer

🔍 References

😁 Let's chat!

Taiko's Proximity Selectors

🔨Installing Taiko

👉Using a proximity selector

🤝 Thanks

🔍 References

😁 Let's chat!