Forem: fullstackcoder

SpecFlow - Selenium - ChromeDriver code base

fullstackcoder — Mon, 27 Dec 2021 17:53:00 +0000

Disclaimer: This is a starting point to build on top of the existing code base, implementing BDD E2E automation testing. As stated in the README, the setup contains minimal configuration (not using Context Injection). English is not my first language, so my apologies for any mistakes.

Brief
When it comes to automated testing (BDD, E2E etc) in .NET, the most popular framework at the moment is SpecFlow, combined with Selenium and among the several webdrivers, ChromeDriver is the one used the most.

In this repo I created a code base, adding a few Scenarios, to showcase the above setup, by testing an existing application. I hope this will be useful to anyone starting messing around with BDD on .NET and will save you time from creating the setup from scratch.

If you would like to support this effort to provide tutorials and demo code, please like us on Facebook or even ☕ Buy Me A Coffee

.Net AWS MQ

fullstackcoder — Sun, 28 Nov 2021 13:40:46 +0000

Disclaimer: In this article I give a brief on how to interact with Amazon MQ (using the ActiveMQ engine) from a .Net6 application via MassTransit providing boilerplate code and instructions. This is a high overview and not a step by step guide. Finally, English is not my first language, so my apologies for any mistakes.

What are we building
This is a Proof of Concept aiming to demonstrate the integration of AWS AMQ (Pub/Sub) into .Net via MassTransit. In this repository there are two elements under a single Solution:

WebApi Project containing an ApiController and endpoint which is allowing posting to AMQ via a MessagingService
A console (dummy) application which consumes the messages from the previous step

Prerequisites
It is expected to have an AWS Account.

Create a broker
This is an extensive and descriptive enough tutorial on how to create an AMQ broker. Just to highlight that AmazonMQ supports two engines: ActiveMQ and RabbitMQ. We are going for the ActiveMQ option. The broker creation process takes approximately 15-20 minutes to complete.
Important: Make sure to use one of the smaller EC2 instances and not the default large one.

Setup the project
To make the project up and running there are few actions to be taken:

Replace the credentials in the (Producer) WebApi project ( appsettings.json ):

  "AMQ": {
    "Username": "{broker_username}",
    "Password": "{broker_password}",
    "HostUrl": "activemq://{broker_endpoint}",
    "queueName": "{broker_queue_name}"
  }

Replace the credeitnals in the (Consumer) Console Application:

string username = "{broker_username}";
string password = "{broker_password}";
string hostUrl = "activemq://{broker_endpoint}";
string queueName = "{broker_queue_name}";

Start both projects in parallel. To achieve this, right click on the Solution and through the properties:

Demo

More info about Amazon MQ can be found here
Remember to delete the broker once finished if there is no other usage apart from demoing
Broker's configuration cannot be deleted
Broker's configuration can be used by multiple brokers

If you would like to support this effort to provide tutorials and demo code, please like us on Facebook or even ☕ Buy Me A Coffee

.Net Generic Repository Pattern

fullstackcoder — Sun, 21 Nov 2021 13:04:38 +0000

Disclaimer: In this article I provide demo code implementing the Generic Repository Pattern via .Net6 and C#. This is a high overview and not a step by step guide on how to start the project from scratch. I don't expect everyone to agree with the statements below since there are many different ways to implement this Pattern. Finally, English is not my first language, so my apologies for any mistakes.

The Generic Repository Pattern is a wide used way to keep a neat codebase on the Data Access Layer, keeping commonly used CRUD functionality grouped together, giving the ability to make it reusable among the different entity types.

The core concept of the Generic Repository Pattern is that regardless the passed-in data type, the CRUD functionality will adapt to it and will operate the same way. To achieve this, we make use of C# Generics feature.

A Base Generic Repository (async) interface would like this:

    public interface IGenericRepository<T>
    {
        Task<IEnumerable<T>> AllAsync();
        Task<T> GetByIdAsync(string id);
        Task<T> CreateAsync(T entity);
        Task<T> UpdateAsync(T entity);
        Task<string> DeleteAsync(string id);
    }

"T" represents the generic type, it could be understood as a "placeholder" for the different data types.

The implementation of the above interface, using Entity Framework, would like this:

    public class GenericRepository<T>: IGenericRepository<T> where T: BaseEntity
    {

        protected readonly DatabaseContext _context;

        public GenericRepository(DatabaseContext context)
        {
            _context = context;
        }

        public async Task<IEnumerable<T>> AllAsync()
        => await _context.Set<T>().ToListAsync();

        public async Task<T> CreateAsync(T entity)
        {
            entity.Id = Guid.NewGuid().ToString();
            entity.DateUpdated = DateTime.Now;

            await _context.AddAsync(entity);
            await _context.SaveChangesAsync();

            return entity;
        }

        public async Task<string> DeleteAsync(string id)
        {
            var entity = await _context.Set<T>().FindAsync(id);
            _context.Set<T>().Remove(entity);
            await _context.SaveChangesAsync();

            return id;
        }

        public async Task<T> GetByIdAsync(string id)
        => await _context.Set<T>().FirstOrDefaultAsync(x => x.Id == id);

        public async Task<T> UpdateAsync(T entity)
        {
            entity.DateUpdated = DateTime.Now;

            _context.Set<T>().Update(entity);
            await _context.SaveChangesAsync();

            return entity;
        }
    }

As mentioned above, the aim of the base repository is to be shared between other repositories, in order to make use of the already implemented functionality. An example of usage in an individual feature repository interface:

    public interface IVehicleRepository : IGenericRepository<Vehicle>
    {
    }

The above IVehicleRepository inherits the functionality of the IGenericRepository, passing the Vehicle entity to it. In other words, IVehicleRepository is informs the IGenericRepository that it is going to use the CRUD methods against the Vehicle object. And down to the exact feature repository implementation now:

    public class VehicleRepository : GenericRepository<Vehicle>, IVehicleRepository
    {
        protected readonly DatabaseContext _context;

        public VehicleRepository(DatabaseContext context) : base(context)
        {
            _context = context;
        }
    }

The full implementation of the above code can be found here In this demo project I make use of some of the commonly used techniques, features and tools, including: Generics, DI, Async, Entity Framework (InMemory Database), Automapper, XUnit, FluentAssertation, Moq

If you would like to support this effort to provide tutorials and demo code, please like us on Facebook or even ☕ Buy Me A Coffee

Code review - the mature way

fullstackcoder — Sat, 07 Aug 2021 22:47:13 +0000

Disclaimer: In this article I list the key points I consider every time I do a code review. This is not a step by step guide on how to do code reviews. I don't expect everyone to agree with the statements below. Finally, English is not my first language, so my apologies for any mistakes.

Code reviews is the time of judgment (this meant to be a joke) - it's the place where you give the opportunity to other developers to validate the piece of code you proudly worked on. Regardless you are a junior or senior developer, there will always be something you might have missed in your code, or could be written in a better way.

There are times where code reviews turn to be a battlefield between the reviewer and the code author though. But this should not be the case. Remember, the result of a code review is to merge a valid and clean piece of code into the code base. Thus, as reviewer, the comments you submit should be relevant, the wording proper and the observations straight to the point. On the other side, as the author of the code, any comments should be welcome and same thing here, any replies to be in proper language.

But anyway it's not always about code, there are few other aspects to pay attention when reviewing code. I list below some of my technical and non-technical criteria I have in mind every time I do a code review.

Technical considerations

Firstly I usually go quickly through the code in order to check for any obvious:
typo/ misspelling /readability, code coverage, linting, code smell, duplications in the newly introduced code, naming, magic strings and numbers. For most of these we can also rely on automated checks - Sonarqube for example is a widely used tool that helps to identify the mentioned issues upfront, reducing the manual reviewing time.

I then have a second look to check as for coding principles (example SOLID standards), simplicity and reusability. For big (usually legacy) projects, I try to check if any of the introduced code exists somewhere else in the code base so we can use the existing one to avoid reinventing the wheel.

Consider a better syntax. There will always be a better way to write a certain piece of code. But it is important to use the most up to date syntax and features of the language or framework we are using so we can take the most out of it, taking advantage of their functionality. Here I try to keep the balance between "you could change it" vs "you should change it" and this is because I try to respect the developer's programming style as well. In these situations I usually put as a suggestion the requested change, highlighting that this is how I would write that.

Non-technical considerations

What the ticket is all about. In an agile environment, every submitted piece of code should follow a previously discussed ticket (whether this is a story, a task or a bug). As a first step so, I check if the provided code, satisfies the acceptance criteria of the ticket. As part of this I try to identify any edge cases too - any use cases that might have missed from the ticket's criteria and they should be handled as part of this work.

What exactly the merge request (pull request if you like) contains. Some times we tend to sneak small amends as part of another merge request, in order not to raise a separate ticket and merge request. It is practical every merge request to contain (relatively) small changes and this is because if for some reason we have to roll back the master branch, then all this work will go wasted. Small merge requests are digestive - easy to review and be tested - so we can keep rolling smoothly.

Commit message is part of my reviewing process too. Looking the commit logs in a later point of time we should have a list of meaningful commits and even better, to contain the ticket number where this change had to be introduced for. To get this further, having straight to the point commits can be useful for when investigating (possibly as part of debugging) an area into the code - a git blame on a specific line of code will reveal the commit message so it makes sense to meet a meaningful commit in order to understand the existence of this line.

Finally, I want my reviews not to affect productivity so before I leave a comment I have always in mind a couple of things which I group together here:

Time spent on the ticket. If a ticket is under development for too long, then adding less important comments it will delay the delivery even more. In these situations I try to leave the necessary comments - any lower priority observations can be addressed in a later ticket.
Urgency. If a ticket needs to move fast (for example bug on production) then I skip the steps for better syntax, naming etc. For an urgent bug, I am more open to allow a quick solution from a more proper one, in order to resolve the direct problem and satisfy the end user, but always follow up to improve this piece right after. Remember, our projects have to be as perfect possible in terms of code but they should also be functional for the end user.

Code reviews is a chance to see the problem from different angles and consider different (or maybe better) ways to resolve it. Both sides should be open to submit and address valid comments on the code. There should be no ego or arrogance in this - no hard feelings at all! Better few and meaningful words (pointing some documentation and resources if needed) from a tone of comments that may not make sense in some cases.

Thanks for reading this. If you want to show me some love, you can always ☕ Buy Me A Coffee

Why VueJs is the next big thing - a personal perspective

fullstackcoder — Sat, 02 Nov 2019 16:27:04 +0000

Disclaimer: In this post I list those things that triggered my interest on VueJs and I do not expect everyone to agree with the statements below. This is not a competition for the best front-end framework/library. The following post is a result of my exposure working on Angular, VueJs and React as a professional. Feel free to place your own thoughts on the comments and possibly end up in a robust conclusion. Finally, when mentioning Angular, I am talking about Angular 2+ and not AngularJs.

It's a fact that the decision for which library to use depends on which of those tools could cover your needs each time. As a professional I worked on the most popular ones (Angular, React, VueJs), I found all of them equally great, but I dare to say that VueJs is my favorite one. Like it is mentioned in several posts, VueJs is a combination of React and Angular and I totally agree with that - VueJs actually embrace the greatest features of Angular and React.

Googling around, I found out that most of the blogs are talking about the popularity of the front-end frameworks and libraries considering graphs and job postings, numbers of downloads per library etc. I will try to make my approach more practical, naming those features that VueJs "borrowed" from Angular and React and I like the most. Long story short, here we go:

Two-way data binding

..or else "model binding". By saying two-way data binding in a general term means that any changes to the model object, will affect the UI and vice versa. I find this feature very handy in terms of code maintenance and possibly readability. Two-way data binding is used in VueJs and Angular but not in React. When working with React, you have to manually bind the updates by calling a function from the event handler - most of the times this is nothing more than a lambda function which updates the state by setting the current value - but still this is a concern which could be avoided by having the two way data binding feature.

Easier integration in an existing project

Although all the three of them can fully cover the needs of a Single Page Application solution, there are also those cases where you just need to write a piece of more elegant javascript without having to carry on the whole framework/library. A real case scenario I usually face is when I want to add some ajax calls in a legacy Multiple Page Application (written let's say in .NET MVC with Razor) and I want to avoid using the "obsolete" to me JQuery. I am not saying that JQuery is not doing the job, but even pure javascript can do the job either. So since we are moving forward, I guess that a more modern solution could be more effective. This is where VueJs and React are dominating - it is quite easy to include a bit of VueJs or React code in a "non VueJs" or "non React" application. Although Angular introduced the Angular Elements it is still not a straight forward way to apply them outside an Angular application. Basically this is because Angular was introduced as a framework, when React and VueJs as libraries, so this is a nice starting point for the next listed feature.

Grow as you go approach - initial package size

Like it was mentioned before, Angular comes as a full solution for Single Page Applications so the initial package of (approx) 500KB contains all the relevant tools like the Router, HttpClient, built-in form validation, built-in pipes etc. As such, whether you need them or not, Angular will install them by default. VueJs and React (80KB and 100KB each) offer some more flexibility/scalability though. The initial installation is in a more frugal format and any extra packages can be installed thereafter. So at first place you get only what you need and as long as your needs grow, you can extend the setup with more tools.

Functional and Class components

Red wine, white wine.... I presume that this decision is mostly depending on each developer's style or even on the team's agreed code guide but still. Having the option to choose between Functional and Class components is offered in VueJs and React but not in Angular. I am not saying it's good or bad using one way over the other, but still it is a level of freedom that Angular is not supporting anyway. With Angular the only option is the Class components.

Built-in API

Following the previous thought, this one is a matter of personal preference as well. Comparing React and Angular, I find that Angular offers a massive API and this can be either good or bad. The Angular API covers tons of use cases in a new syntax, when React API is simpler and relies in a lower level (pure javascript). Obviously this is something that affects the learning curve as well. Thankfully VueJs contains a simple enough (to adapt quick) API but not that extensive like Angular. A conditional iteration in a VueJs component's template for example can be achieved by v-for and v-if (*ngIf, *ngFor in Angular) etc when in React we have to play with more pure javascript commands like map, spread operator etc. But again, this is a matter of personal preference.

Separation of Concerns

Separation of concerns is one of the fundamental principles when talking about professional coding. Organizing the code in sections by having each section responsible for a specific operation prevents a lot of problems in terms of code maintenance and readability. In VueJs and Angular the components hold the html, javascript and css in separate code blocks and that increases the readability possibly but for sure, it serves the Separation of Concerns Principle. On the other hand, React introduces the JSX syntax which is a mixture of javascript and html because of the belief that those two are a bit of tied to each other.

To summarize, there is no good and bad library/framework. The first step in order to choose what suits our case, is to consider the needs of this case in depth. All the three mentioned tools (Angular, VueJs and React) were built by skillful developers and the aim was to be used efficiently by developers. As a personal preference though, VueJs is my favorite tool for the reasons mentioned above. Your opinions are also welcome

☕ Buy Me A Coffee