Category Archives: Development

Continuous Delivery Best Practices

Posted on by
Reply
  • Automate everything. The more you can automate, the less manual work you’ll have to do, and the less likely you are to introduce errors.
  • Use a version control system. This will help you track changes to your code and roll back changes if something goes wrong.
  • Write unit tests. Unit tests are small tests that verify the functionality of individual units of code. They help you to catch bugs early and prevent them from being released to production.
  • Write integration tests. Integration tests verify the functionality of your code as a whole. They help you to catch bugs that would not be caught by unit tests.
  • Write end-to-end tests. End-to-end tests verify the functionality of your application from start to finish. They help you to catch bugs that would not be caught by unit or integration tests.
  • Use a continuous integration (CI) server. A CI server automates the build and test process. This helps you to catch bugs early and prevent them from being released to production.
  • Use a continuous delivery (CD) server. A CD server automates the deployment process. This helps you to deploy your code to production quickly and reliably.
  • Monitor your deployments. Once you’ve deployed your code to production, it’s important to monitor it to make sure that it’s working properly.
  • Have a rollback plan. In case something goes wrong with your deployment, it’s important to have a rollback plan in place so that you can quickly restore your application to its previous state.

By following these best practices, you can improve the quality of your software, reduce the risk of errors, and speed up the time it takes to deliver new features to your customers.

How Do I Implement Continuous Testing?

Posted on by
Reply

Continuous testing is a software development practice where tests are executed automatically at every stage of the software development lifecycle. This helps to ensure that the software is of high quality and meets the requirements of the users.

There are many benefits to implementing continuous testing, including:

  • Improved quality: Continuous testing helps to identify defects early in the development process, when they are easier and less expensive to fix.
  • Increased confidence: Continuous testing gives developers and stakeholders confidence that the software is of high quality and meets the requirements.
  • Reduced risk: Continuous testing helps to reduce the risk of defects being released to production, which can save time and money.
  • Faster time to market: Continuous testing can help to speed up the time it takes to bring new software to market.

There are a few things you need to do to implement continuous testing:

  1. Identify your test cases: The first step is to identify all of the test cases that need to be executed. This can be done by creating a test plan or by using a test management tool.
  2. Automate your tests: Once you have identified your test cases, you need to automate them. This can be done using a variety of tools, such as Selenium, JUnit, and Robot Framework.
  3. Integrate your tests into your CI/CD pipeline: Once your tests are automated, you need to integrate them into your CI/CD pipeline. This will ensure that your tests are executed automatically every time you make a change to your code.
  4. Monitor your test results: It is important to monitor your test results to ensure that your tests are passing. This will help you to identify any defects that are introduced into your code.

By following these steps, you can implement continuous testing in your software development process. Continuous testing can help you to improve the quality of your software, increase confidence, reduce risk, and speed up time to market.

Top 10 Ideas for Successful Continuous Testing

Posted on by
Reply

Continuous Testing in 2022. It’s the stuff that Continuous Delivery is built upon. Do it right, and you deliver software at pace. Do it (CT) poorly, and you get nothing but a script to deliver crappy software just like we always have. CD without CT is just a pipe(line?) dream.

So how do you do it right? Lets take a look at 10 ideas that make Continuous Testing effective and successful:

  1. Automate your acceptance criteria
    • Start with a great acceptance criteria. Now take test automation and prove that you did it. Don’t stop short, don’t wave your hands and say it will work. Prove it with a test. Check it in with the code and run it every time you build. This is your oracle for the future. This is where you start putting coins in the bank for the future.
  2. Make your tests focused and fast
    • Forget end to end if you can. Focus your test on a single thing. Sure, write great unit tests that help show function level quality, but strive to create a test that proves working components. System level functionality (not system integration) – make your tests fast. Make them small, with limited scope. Get in, prove, clean up and get out. If you are doing setup to get to your point, you have failed. Think testability and architecture. Refactor so that your test is small, focused and fast.
  3. Develop and live by a definition of done that includes testing in your sprint
    • Your team must live by the fact that you are not done until you have delivered test automation that proves your code is going to work. Sure, that might not happen but that is the cliff we march to. We may find out that our test was not good enough, but the sprint is not done until we have the completed code and tests to go with it checked in and passing. No excuses.
  4. Make the entire team responsible for quality
    • People say this all the time and don’t live by it. Many times we sit around waiting for quality guy or gal to get the testing done. Wrong. If you are waiting for testing to complete, you are doing it wrong. Complete the testing. Make the testing faster. Do the test yourself. Build better testing. Make the framework measure. Your job is to deliver new features with high quality. Whatever your expertise is, use it. You are responsible. I once heard that the best way for a developer to get better at testing is to give them a pager. Give everyone a pager.
  5. Get skilled. Quit pretending that record and playback works
    • Laugh at the sales guy that brings the record and playback “we can make automators out of everyone” BS. It’s a lie. Always has been, always will be. Get some skills on your team – it takes code and hard work by well paid professionals. Big projects will have quality roles for SME’s and analysts with deep product knowledge but we are talking about Continuous Testing here. Automation. It takes engineering – don’t lie to yourself or get lied to by vendors.
  6. Tell your sponsors that systems without tests will not be delivered
    • Hey PM or Product owner. We write quality code. To do that, we have to write tests. It’s part of our estimates. We won’t be done with the sprint without the test automation. There is no CD without CT. Get over it. No, we will not start working on another feature until this one is done, tested, automated and complete. If you need us to skip test automation, please see #6.
  7. Listen to the tests
    • Thou shall not comment out, delete, cripple, or ignore your tests. You built them. If they are complaining, make them better. If they are failing, listen to what they say.
  8. Fight fragility. Mock, isolate, make the tests small
    • Fragility is your enemy. Make your tests boringly pass all of the time. If fragility is your problem, think testability, observability and architecture. Take the battle to the system under test and the way it is designed if there really is no way to stabilize your tests. Mock and isolate your testing using responders or other service virtualization if you can. Resist giant integration tests when small tests will cover the risk. If they are fragile, get everyone in the room and figure this one out – it’s too expensive to live with.
  9. Co-exist your tests
    • Never, ever let your test automation live in another place. They are first class citizens that should live with your production code (I didn’t say deployed with) and should most often be written in the same languages that the system is. Everyone whould be able to fix them. Never let there be an excuse of “i don’t understand that code” or “that harness is in another solution, get Jane/Jack to look at it”. Nope. Not Continuous Testing. Let them co-exist.
  10. Monitor everything, measure FTW
    • Monitor your systems. Measure your testing. Continuous Testing really works when you instrument your systems from production down to have machines looking at things that may help you diagnose and fix quick a problem that is on tested for initially. When you find problems this way, maybe you should go back, and write some test automation. FTW.

Copyright 2022 HeadRevison.com

Testing in Production

Posted on by
Reply

This is a topic that always draws some great responses when discussed where I work. Do you Test on your production systems?

I always come to the same conclusion on this one. Why wouldn’t you want to test in production? I know, I know. Your system is too “special” or “secure” or “regulated” or whatever to be able to test in production. So what are you going to do? Let your customers test it for you? Throw the code over the wall to the people that matter most and hope that it works for them? Take the chance that your customer will just understand when the house of cards comes crashing down in a burning heap of lame?

To those that say it just can’t be done, I say that maybe your system is just lacking testability – you haven’t built it right. To me a testable system is one that has a great handle on control and is inherently observable. If you can’t control and observe the software, you are dead out of the gate. Often, if you solve the control and observation issue, you will find a system that you can test in production – because you engineered it to be easy to do so in any environment.

So take a look at your systems and ask yourself if there are any measures you can take to affect the testability of your system in a way that would lead you to be able to test your system in production. Face it, no matter how you try, your QA systems will never be the same as your production systems. The data, traffic, configurations, scale, timing, etc. will just never match well enough that the tests you run in those environments will catch everything. Change control, make it observable and make sure your system works in production before your customer does it for you!

Centralized vs. Federated Integration Test in the Enterprise

Posted on by
Reply

I have been working on the question of federated vs. centralized integration test practices in the enterprise lately. As I have done some research into the topic, I have found that few resources are around on the topic. While some white papers exist, it appears that most companies are in the federated camp: relying on individual divisions to create their own integration test strategies – even when there are many ties among their applications that could benefit from a centralized approach.

Some companies like Google have extremely large tests that involve many applications, and even automate them to some extent. Most though, including the ones that I have worked for, spend time testing software from within their respective silos in an effort to protect their own. Each of these groups tend to create and maintain redundant sets of tests that cover their application needs.

The problem is that many of these needs are the needs of many of the other groups and a great deal of redundant and poorly performing tests are written. Every group creates a test to “create a user and password” for instance. Each is created in their silo and when the functionality changes, each breaks in their own way. Tests that perform things as trivial as this, and of course much more elaborate are created all of the time that could be shared.

Creating a centralized integration test group may be able to fix this redundancy issue and help protect production quality as you do so. Sharing resources, test data management, and testing know how might be a way to create a group that solves the issue of poor communication across your organization when it comes to system integration test. This one set of testers will help build the “moat” that protects your production castle from impending doom.

Android Shared Preferences Backed Up

Posted on by
1

I have been looking around for some way to back up the preferences in my Android app – just a simple serialization of the SharedPreferences object. Here are some code snips from my backup object that allowed me to get the job done:

private void importSharedPreferences()
{
  SharedPreferences prefs = getSharedPreferences(PREFS_NAME, 0);
  File myPath = new File(EXPORT_FILE_PATH);
  File myFile = new File(myPath, PREFS_FILE_NAME);
  if(myFile.exists())
	{
		BufferedReader i = new BufferedReader(new InputStreamReader(new FileInputStream(EXPORT_FILE_PATH + PREFS_FILE_NAME), "UTF8"));
		String line;

		while ((line = i.readLine()) != null)
		{
				String[] pair = line.split(":");

				SharedPreferences.Editor prefEdit = prefs.edit();

				if(pair[2].indexOf("Boolean")>-1)
				{
					prefEdit.putBoolean(pair[0], Boolean.parseBoolean(pair[1]));
				}
				else if(pair[2].indexOf("Integer")>-1)
				{
					prefEdit.putInt(pair[0], Integer.parseInt(pair[1]));
				}
				else if(pair[2].indexOf("Float")>-1)
				{
					prefEdit.putFloat(pair[0], Float.parseFloat(pair[1]));
				}
				else if(pair[2].indexOf("Long")>-1)
				{
					prefEdit.putLong(pair[0], Long.parseLong(pair[1]));
				}
				else if(pair[2].indexOf("String")>-1)
				{
					prefEdit.putString(pair[0], pair[1]);
				}

				prefEdit.commit();
			}
	}
}
public void exportSharedPreferences()
{
    SharedPreferences prefs = getSharedPreferences(PREFS_NAME, 0);

    File myPath = new File(EXPORT_FILE_PATH);
    File myFile = new File(myPath, PREFS_FILE_NAME);

    FileWriter fw = new FileWriter(myFile);
    PrintWriter pw = new PrintWriter(fw);

    Map<String,?> prefsMap = prefs.getAll();

    for(Map.Entry<String,?> entry : prefsMap.entrySet())
    {
    		pw.println(entry.getKey() + ":" + entry.getValue().toString() + ":" + entry.getValue().getClass());
    }

    pw.close();
    fw.close();
}

I removed all of the error handling and might have messed up the formatting a bit, but you get the idea. Also, I plan on moving the serialization to a XML format in the next few days instead of the janky colon-separated bit. Hope this is helpful to you!

Exporting MS SQL Schema

Posted on by
1

I seem to forget this one, though I have to do it now and then, so I thought I would share this in a post. Somehow I always find myself digging into “Script Database As” instead of the much less appropriately named “Tasks” – which is where you want to be. If you want to export the schema of your MS SQL database, here is what you do:

  1. Open the Microsoft SQL Server Management Studio, and connect to the database
  2. Expand the Databases node, and right click on the database you want to export the schema for
  3. Choose “Tasks” (in 2005 “All Tasks”) then “Generate Scripts”
  4. Navigate through the wizard choosing your database
  5. You can choose “Script all objects in the selected database” on the “Select Database” page, or hit next and choose the individual objects on the following screens like Options, Schema, Tables, and Users
  6. Finally you will find the schema and tables to select
  7. On the last page of the wizard you can choose to output the schema to file, clipboard or to a new query window

Hope you find that useful!

C# Path of dll vs. Application path vs. EntryAssembly path vs. Form path

Posted on by
1

OK, I have stumbled on this one a few times so I thought I would blog it up so that I had a place to come and find the answer. The problem most recently was an application I wrote that I use as a command line tool, but other times as a class that hits a constructor. Either way a property file is needed, and depending on the way I call it I had trouble finding the path to the config…

The problem is, when you use Microsoft Visual Studio to launch the debugger, the Application.StartupPath can’t be relied upon, as it points to the Studio directory. At run time it might work, but not for the case I had in mind where I needed to know where the DLL itself was.

So you can use this:

System.Windows.Forms.Application.StartupPath

But that is for a windows form startup path – useful, but not for me.

This will give you the directory the app started in (but again, it may be a Visual Studio directory if debugging):

Application.StartupPath

And this will give you the process executable in the default application domain, or the first executable that was executed by AppDomain.ExecuteAssembly – again, not what I needed:

System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetEntryAssembly().Location)

Finally, the winner is (and look closely – GetExecutingAssembly vs. GetEntryAssembly)

System.IO.Path.GetDirectoryName(System.Reflection.Assembly.GetExecutingAssembly().Location)

This snip allowed me to find the directory where the DLL was currently executing, and thus the config that sits next to it. So many ways to get at run-time information! Hope that helps you!!

Google Android Market VS. Amazon Appstore

Posted on by
Reply

There are plenty of 2nd party App-Store wanna-be’s out there like SlideMe.org, AndroLib, AndAppStore and others that have tried hard to crack the Google Android Market gold mine, but have had only mild success. While Google rested on their “we own it” laurels, and did little to bring the Android Market to the public in bigger ways, monsters like Amazon now loom in the background – threatening t o bring real web development and internet sales skills to the table.

Google may have the lions share of the app sales game at the moment in the Android space, but are they moving too slow to lead?  Recently the search giant introduced a new web presence for the Android Store that allowed online browsing, and push to phone – something sorely missing from the Android experience, but possibly too little too late.Google needs to step up their game here I think, or the doors might be open exposing the castle keep here.

The thing with smart-phones and app stores is that they need to be sexy! You have 10 minutes to kill, so you turn on your phone, hoping to be amused, informed, amazed. Google’s less is more search interface, while perfect for the desktop experience, doesn’t fly here.  The current Android Market web experience is like it came from the same department – sans sex. Google needs to bring in some designers and marketers that know how to make me A) open their app store when I have 10 minutes, and B) be excited to be there and get new stuff.

Amazon has recently moved into Google’s space with their Appstore.  Having looked at it from the beginning, months prior to the release, I can say that they have really come a long way.  In fact, I think maybe they have even one-upped the big G’s gold standard. They have editors (that are used to selling stuff!!) writing content for app descriptions, and have an app submission process that is getting pretty sweet. Their one click purchase system makes it a breeze to get that new app, and their Appstore is fresh and feels right.

Look for more competition in this space, as there is plenty of money to be made here.  For now, these two behemoths have the dance floor and while it may not yet be even money, look for Amazon to do everything in it’s power to be in mobile as a formidable leader.

TFS Instance Appears Read Only Until Mapped

Posted on by
Reply

OK, I’ve run into this one with Microsoft’s TFS server a few times so i thought I would talk about it to help me remember it.  MS has come a long way with their version control software, with TFS light years ahead of some of the old versions of Visual Source Safe, but there are always “duh” moments that a co-worker helped me to remember today.

At my job we use a single TFS server and have instances that are created for various groups in the company.  If you want access to another instance you open a ticket with the IT folks to give you permission to get at it.  There are 2 types of access, read only, and an “Advanced” developer mode that gives you the keys to the candy store.

After my request for total control of the TFS repository was completed, I went into Team Explorer and then into Source Control and saw the new instance ready to go.  I wanted to create a directory and start adding some code to the repository but noticed that by right clicking “New Folder” was grayed out.  All I saw was “Refresh” and “Add items to Folder”.  My security request had surely been mishandled I thought (or less likely I had asked for the wrong access 😉 ).  I opened another ticket and got – “You already have “Advanced” stupid”.

Well, a few minutes scratching my head had me stumped and wondering what to do.  I checked with the owner of the repository and he said I should be good to go as long as I have advanced.  Oh, and have it mapped correctly.  Mapping!!!  This is the key!  Just because the repository is shown in your Source Control Explorer, until you have it mapped you might as well only have read access.  So I right click on the instance, choose “Map to Local Folder” and enter the path that I want to map it to and POW! – we have liftoff!  I now have a correctly mapped folder that I can create folders and add content to my hearts content.  On to the coding!