In this ad-hoc testing tutorial, let’s dive deep into what ad-hoc testing is, its advantages, disadvantages, types, characteristics, and best practices.

In this tutorial, we'll show you how to use Testcontainers for integration testing with Spring Data JPA and a PostgreSQL database.

In this detailed article, you will learn how to carry out data ingestion and analysis using Azure Synapse Serverless SQL Pool along with sample datasets.

This article covers the benefits of integration, steps for setting up AWS resources and configuring Salesforce, and provides Terraform code examples.

In this tutorial on Alpha testing, let’s dive deep into the objectives of Alpha testing, its advantages, disadvantages, phases, process, and best practices.

This detailed tutorial will teach what Test Data is, why it is crucial for testers, its advantages and disadvantages, and more.

The Microsoft Teams integration with Cypress allows you to see your test results directly in your Microsoft Teams channels.

Here’s how you can simplify test-driven development and continuous integration with Redpanda and Testcontainers and Quarkus.

Explore this blog to gain a comprehensive understanding of retesting, including its definition, examples, pros, cons, and significance.

Robust regression test execution reports show how important they are and the value they bring to the product, even more so if they are automated and run continuously.

Learn about Exploratory Testing with our comprehensive tutorial. Discover what it is, why it's important, its benefits, and how to perform it with real-life examples.

Level up your automation testing skills with our comprehensive Cypress Testing tutorial. Don't miss out on the opportunity to master this powerful tool.

A comprehensive end-to-end Testing tutorial that covers what E2E Testing is, its importance, its benefits, and how to perform it with real-time examples.

Organizations can enhance their overall system performance with chaos engineering. This is because teams can pinpoint bottlenecks by testing the system's resilience.

This guide explores how to auto-scale your Kinesis Data Streams consumer applications on Kubernetes so you can save on costs and improve resource efficiency.

Learn about the world of AWS file handling, how it is revolutionizing cloud storage, and discover the different ways you can manage your files.

Real-time debugging tools and techniques can help beginner mobile app developers identify and resolve errors quickly, improving app performance and user experience.

My last article raised an interesting discussion whether you should see tests more as documentation or more as specification. I agree that they can contribute to both of them, but I still think tests are just - tests... There were also complaints about my statement that testing often becomes tedious work which nobody likes. Also here I agree, that techniques like TDD can help you to structure your code and make sure you code exactly what is needed by writing the tests, but the result of the process will still be a class which needs to be tested somehow. So I have set up another small challenge to show how the visual approach featured by MagicTest helps to make testing a breeze. As you know, traditional assertion-based test frameworks like TestNG or JUnit force us to include the expected results in the test code. Where this may be more or less suitable for simple tests (like in the previous article), it quickly becomes cumbersome if the test handles complex objects or voluminous data. The Task We must test the method createEvenOddTable() (see appended ) with the following functionality: Create HTML table (elements table, tr, td) with specified number of data rows and columns. An additional row will be added to store header information (element th). An additional column will be added which contains the row number (element th) The rows will have attribute class set to "head", "even", or "odd" for easy styling. Both the specification (the 4 lines above) and the source code itself (25 lines) are short and simple to understand, so any experienced developer will write this method in a few minutes. So what's the problem with testing this method? We will see if we look at how MagicTest handles this case. The Magic Test The MagicTest for this method looks like this: public class HtmlTableTest { @Trace public void testCreateEvenOddTable() { HtmlTable.createEvenOddTable(4, 3); } @Formatter(outputType=OutputType.TEXT) public static String formatElement(Element elem) { XMLOutputter serializer = new XMLOutputter(); serializer.setFormat(Format.getPrettyFormat()); return serializer.outputString(elem); } } Some details: We use the @Trace annotation to automatically capture information about calls to the method under test. We rely on naming conventions, so the method HtmlTable.createEvenOddTable() is tested by HtmlTableTest.testCreateEvenOddTable(). Per default, MagicTest uses the toString() method to report the parameter and return values. As the Element's toString() method returns only its name, we have to define a custom @Formatter to get the full XML tree. If we run the test, we get the following report: If we look at the XML element tree in the report, we can see all the details which a complete test should cover: correct nesting of elements (table, tr, td), correct header line, correct line numbers, correct number of rows, correct number of cells for each row, correct class attribute for each row, etc. But even if you end up with a bunch of lengthy assert statements like assert("head".equals(((Element) elem.getChildren("tr").get(0)).getAttributeValue("class"))); which tests for the correct class attribute, this will not be enough: you should also test the absence of the class attribute for all cells except the first ones in each row. So yes, for a sound test you must actually verify the whole XML tree - and this is exactly the information which MagicTest shows you for confirmation. Let the Challenge Begin To run the test yourself, you will need to download the MagicTest Eclipse plug-in. Copy it into the Eclipse dropins folder and restart Eclipse. Then download the attached Eclipse project and import it into your workspace. Run the test class TagsTest by executing Run As / MagicTest. After the first run, the test report will show up and all test steps will be red. This is the MagicTest way of telling you that a step has failed. In our case, the steps just fail because MagicTest simply does not know anything about the expected result. So we carefully check the output and confirm its correctness by clicking on the save button. Now all steps are green - and the test is successful. You have now seen how efficiently this test can be realized using MagicTest - it even looked like fun. Does your test tool accept the challenge? How many minutes and lines does it take you to write the test? I'm looking forward to your contributions! Appendix: Listing HtmlTable /** * Create HTML table (elements table, tr, td) with specified number of data rows and columns. * An additional row will be added to store header information (element th). * An additional column will be added which contains the row number (element th) * The rows will have attribute class set to "head", "even", or "odd" for easy styling. * * @param rows number of rows * @param cols number of column * @return XML element containing the HTML table */ public static Element createEvenOddTable(int rows, int cols) { Element table = new Element("table"); for (int r=0; r 0) { td.setText(Integer.toString(r)); } } } return table; }

You don't generally hear that you should develop for Android first, but even if you go iOS first, Android comes second. That's the traditional wisdom, anyways. According to Semil Shah on Haywire, though, "iOS first" is an understatement. It should be iOS first, and Android in the distant future, if at all. Shah is fairly direct with his point of view: The most common trap here is the early iOS app which gets some buzz. All of a sudden, the founders hear “When are you building for Android?” The natural, enthusiastic response to sincere requests of the Android chorus is to go ahead and build for Android and seek more downloads, more growth, more revenue. I have a different view though. The proper response is: “No. Buy an iPhone.” Shah's reasoning is presented in three central arguments: Android's fragmentation problem is too much for small teams iOS users have all the money (and their numbers are growing) Future Apple hardware (iPhone 5c, for example) may level the playing field And these are some interesting thoughts. The third point in particular is one you don't hear often - one of the big selling points of Android as a development platform is the massive reach, which is a product of the sheer number of phones in consumers' hands. After all, iOS traditionally has a higher barrier of entry when it comes to economics. On the other hand, we've already seen some counterarguments to some of these points. For example, if you ask Nick Bradbury, fragmentation is a completely overblown problem, and according to Danny Roa, there's not really that much point to supporting older devices in the first place. Similarly, Kevin Quach suggests that the common notions surrounding Android's monetization opportunities - that they're not there, basically, at least compared to iOS - are bunk as well. In other words, the "iOS first" vs. "Android first" argument may not be so clear in either direction. Check out Shah's full article for all the details.

In this article, we will discuss the advantages of using AWS and Terraform and provide an example of this collaboration for better understanding.