archive-cr.com » CR » I » INFORMATECH.CR

Total: 292

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Unit Testing 101: Inversion Of Control | Informatech CR Blog
    user DataContext Users GetByName userName string hashedPassword this passwordHasher Hash password Set the user new password user Password hashedPassword Save the user back to the database DataContext Users Update user DataContext Commit More methods public interface IPasswordHasher string Hash string plainTextPassword public class Md5PasswordHasher IPasswordHasher public string Hash string plainTextPassword Hash password using an encryption algorithm Inversion of Control is usually implemented by applying a design pattern called the Strategy Pattern as defined in The Gang Of Four book This pattern consists on abstracting concrete component and algorithm implementations from the rest of the classes by exposing only an interface they can use thus making implementations interchangeable at runtime and encapsulate how these implementations work since any class using them should not care about how they work So in order to achieve this we need to sort some things out Abstract an interface from the Md5PasswordHasher class IPasswordHasher so anyone can write custom implementations of password hashers line 28 31 Mark the Md5PasswordHasher class as an implementation of the IPasswordHasher interface line 33 Change the type of the password hasher used by UserManager to IPasswordHasher line 3 Add a new constructor parameter of type IPasswordHasher interface line 5 which is the instance the UserManager class will use to hash its passwords This way we delegate the creation of dependencies to the user of the class and allows the user to provide any implementation it wants allowing it to control how the password is going to be hashed This is the very essence of inversion of control Minimize class coupling The user of the UserManager class has now control over how passwords are hashed Password hashing control has been inverted from the class to the user Here is an example on how we can specify the only dependency of the UserManager class IPasswordHasher md5PasswordHasher new Md5PasswordHasher UserManager userManager new UserManager md5PasswordHasher userManager ResetPassword luis aguilar 12345 So Why is this useful Well we can go crazy and create our own hasher implementation to be used by the UserManager class Plain text password hasher public class PlainTextPasswordHasher IPasswordHasher public string Hash string plainTextPassword Let s disable password hashing by returning the plain text password return plainTextPassword Usage IPasswordHasher plainTextPasswordHasher new PlainTextPasswordHasher UserManager userManager new UserManager plainTextPasswordHasher Resulting password will be 12345 userManager ResetPassword luis aguilar 12345 Conclusion So this concludes our article on Inversion of Control Hopefully with a little more practice you will be able to start applying this to your code Of course the biggest benefit of this technique is related to unit testing So What does it has to do with unit testing Well we re going to see this when we get into type mocking So stay tuned Further Reading The Strategy Pattern by OODesign Design Patterns Elements of Reusable Object Oriented Software book at Amazon Share this Email Facebook Twitter Like this Like Loading Related April 3 2013 by Luis Aguilar Categories NET Programming 6 Comments Post navigation Unit Testing 101 Basics Overview Of The Task Parallel

    Original URL path: http://blog.informatech.cr/2013/04/03/unit-testing-101-inversion-of-control/?replytocom=1472 (2015-08-19)
    Open archived version from archive


  • Unit Testing 101: Inversion Of Control | Informatech CR Blog
    GetByName userName string hashedPassword this passwordHasher Hash password Set the user new password user Password hashedPassword Save the user back to the database DataContext Users Update user DataContext Commit More methods public interface IPasswordHasher string Hash string plainTextPassword public class Md5PasswordHasher IPasswordHasher public string Hash string plainTextPassword Hash password using an encryption algorithm Inversion of Control is usually implemented by applying a design pattern called the Strategy Pattern as defined in The Gang Of Four book This pattern consists on abstracting concrete component and algorithm implementations from the rest of the classes by exposing only an interface they can use thus making implementations interchangeable at runtime and encapsulate how these implementations work since any class using them should not care about how they work So in order to achieve this we need to sort some things out Abstract an interface from the Md5PasswordHasher class IPasswordHasher so anyone can write custom implementations of password hashers line 28 31 Mark the Md5PasswordHasher class as an implementation of the IPasswordHasher interface line 33 Change the type of the password hasher used by UserManager to IPasswordHasher line 3 Add a new constructor parameter of type IPasswordHasher interface line 5 which is the instance the UserManager class will use to hash its passwords This way we delegate the creation of dependencies to the user of the class and allows the user to provide any implementation it wants allowing it to control how the password is going to be hashed This is the very essence of inversion of control Minimize class coupling The user of the UserManager class has now control over how passwords are hashed Password hashing control has been inverted from the class to the user Here is an example on how we can specify the only dependency of the UserManager class IPasswordHasher md5PasswordHasher new Md5PasswordHasher UserManager userManager new UserManager md5PasswordHasher userManager ResetPassword luis aguilar 12345 So Why is this useful Well we can go crazy and create our own hasher implementation to be used by the UserManager class Plain text password hasher public class PlainTextPasswordHasher IPasswordHasher public string Hash string plainTextPassword Let s disable password hashing by returning the plain text password return plainTextPassword Usage IPasswordHasher plainTextPasswordHasher new PlainTextPasswordHasher UserManager userManager new UserManager plainTextPasswordHasher Resulting password will be 12345 userManager ResetPassword luis aguilar 12345 Conclusion So this concludes our article on Inversion of Control Hopefully with a little more practice you will be able to start applying this to your code Of course the biggest benefit of this technique is related to unit testing So What does it has to do with unit testing Well we re going to see this when we get into type mocking So stay tuned Further Reading The Strategy Pattern by OODesign Design Patterns Elements of Reusable Object Oriented Software book at Amazon Share this Email Facebook Twitter Like this Like Loading Related April 3 2013 by Luis Aguilar Categories NET Programming 6 Comments Post navigation Unit Testing 101 Basics Overview Of The Task Parallel Library TPL 6

    Original URL path: http://blog.informatech.cr/2013/04/03/unit-testing-101-inversion-of-control/?replytocom=1473 (2015-08-19)
    Open archived version from archive

  • Unit Testing 101: Inversion Of Control | Informatech CR Blog
    GetByName userName string hashedPassword this passwordHasher Hash password Set the user new password user Password hashedPassword Save the user back to the database DataContext Users Update user DataContext Commit More methods public interface IPasswordHasher string Hash string plainTextPassword public class Md5PasswordHasher IPasswordHasher public string Hash string plainTextPassword Hash password using an encryption algorithm Inversion of Control is usually implemented by applying a design pattern called the Strategy Pattern as defined in The Gang Of Four book This pattern consists on abstracting concrete component and algorithm implementations from the rest of the classes by exposing only an interface they can use thus making implementations interchangeable at runtime and encapsulate how these implementations work since any class using them should not care about how they work So in order to achieve this we need to sort some things out Abstract an interface from the Md5PasswordHasher class IPasswordHasher so anyone can write custom implementations of password hashers line 28 31 Mark the Md5PasswordHasher class as an implementation of the IPasswordHasher interface line 33 Change the type of the password hasher used by UserManager to IPasswordHasher line 3 Add a new constructor parameter of type IPasswordHasher interface line 5 which is the instance the UserManager class will use to hash its passwords This way we delegate the creation of dependencies to the user of the class and allows the user to provide any implementation it wants allowing it to control how the password is going to be hashed This is the very essence of inversion of control Minimize class coupling The user of the UserManager class has now control over how passwords are hashed Password hashing control has been inverted from the class to the user Here is an example on how we can specify the only dependency of the UserManager class IPasswordHasher md5PasswordHasher new Md5PasswordHasher UserManager userManager new UserManager md5PasswordHasher userManager ResetPassword luis aguilar 12345 So Why is this useful Well we can go crazy and create our own hasher implementation to be used by the UserManager class Plain text password hasher public class PlainTextPasswordHasher IPasswordHasher public string Hash string plainTextPassword Let s disable password hashing by returning the plain text password return plainTextPassword Usage IPasswordHasher plainTextPasswordHasher new PlainTextPasswordHasher UserManager userManager new UserManager plainTextPasswordHasher Resulting password will be 12345 userManager ResetPassword luis aguilar 12345 Conclusion So this concludes our article on Inversion of Control Hopefully with a little more practice you will be able to start applying this to your code Of course the biggest benefit of this technique is related to unit testing So What does it has to do with unit testing Well we re going to see this when we get into type mocking So stay tuned Further Reading The Strategy Pattern by OODesign Design Patterns Elements of Reusable Object Oriented Software book at Amazon Share this Email Facebook Twitter Like this Like Loading Related April 3 2013 by Luis Aguilar Categories NET Programming 6 Comments Post navigation Unit Testing 101 Basics Overview Of The Task Parallel Library TPL 6

    Original URL path: http://blog.informatech.cr/2013/04/03/unit-testing-101-inversion-of-control/?replytocom=1500 (2015-08-19)
    Open archived version from archive

  • Unit Testing 101: Inversion Of Control | Informatech CR Blog
    DataContext Users GetByName userName string hashedPassword this passwordHasher Hash password Set the user new password user Password hashedPassword Save the user back to the database DataContext Users Update user DataContext Commit More methods public interface IPasswordHasher string Hash string plainTextPassword public class Md5PasswordHasher IPasswordHasher public string Hash string plainTextPassword Hash password using an encryption algorithm Inversion of Control is usually implemented by applying a design pattern called the Strategy Pattern as defined in The Gang Of Four book This pattern consists on abstracting concrete component and algorithm implementations from the rest of the classes by exposing only an interface they can use thus making implementations interchangeable at runtime and encapsulate how these implementations work since any class using them should not care about how they work So in order to achieve this we need to sort some things out Abstract an interface from the Md5PasswordHasher class IPasswordHasher so anyone can write custom implementations of password hashers line 28 31 Mark the Md5PasswordHasher class as an implementation of the IPasswordHasher interface line 33 Change the type of the password hasher used by UserManager to IPasswordHasher line 3 Add a new constructor parameter of type IPasswordHasher interface line 5 which is the instance the UserManager class will use to hash its passwords This way we delegate the creation of dependencies to the user of the class and allows the user to provide any implementation it wants allowing it to control how the password is going to be hashed This is the very essence of inversion of control Minimize class coupling The user of the UserManager class has now control over how passwords are hashed Password hashing control has been inverted from the class to the user Here is an example on how we can specify the only dependency of the UserManager class IPasswordHasher md5PasswordHasher new Md5PasswordHasher UserManager userManager new UserManager md5PasswordHasher userManager ResetPassword luis aguilar 12345 So Why is this useful Well we can go crazy and create our own hasher implementation to be used by the UserManager class Plain text password hasher public class PlainTextPasswordHasher IPasswordHasher public string Hash string plainTextPassword Let s disable password hashing by returning the plain text password return plainTextPassword Usage IPasswordHasher plainTextPasswordHasher new PlainTextPasswordHasher UserManager userManager new UserManager plainTextPasswordHasher Resulting password will be 12345 userManager ResetPassword luis aguilar 12345 Conclusion So this concludes our article on Inversion of Control Hopefully with a little more practice you will be able to start applying this to your code Of course the biggest benefit of this technique is related to unit testing So What does it has to do with unit testing Well we re going to see this when we get into type mocking So stay tuned Further Reading The Strategy Pattern by OODesign Design Patterns Elements of Reusable Object Oriented Software book at Amazon Share this Email Facebook Twitter Like this Like Loading Related April 3 2013 by Luis Aguilar Categories NET Programming 6 Comments Post navigation Unit Testing 101 Basics Overview Of The Task Parallel Library

    Original URL path: http://blog.informatech.cr/2013/04/03/unit-testing-101-inversion-of-control/?replytocom=1511 (2015-08-19)
    Open archived version from archive

  • Unit Testing 101: Inversion Of Control | Informatech CR Blog
    User user DataContext Users GetByName userName string hashedPassword this passwordHasher Hash password Set the user new password user Password hashedPassword Save the user back to the database DataContext Users Update user DataContext Commit More methods public interface IPasswordHasher string Hash string plainTextPassword public class Md5PasswordHasher IPasswordHasher public string Hash string plainTextPassword Hash password using an encryption algorithm Inversion of Control is usually implemented by applying a design pattern called the Strategy Pattern as defined in The Gang Of Four book This pattern consists on abstracting concrete component and algorithm implementations from the rest of the classes by exposing only an interface they can use thus making implementations interchangeable at runtime and encapsulate how these implementations work since any class using them should not care about how they work So in order to achieve this we need to sort some things out Abstract an interface from the Md5PasswordHasher class IPasswordHasher so anyone can write custom implementations of password hashers line 28 31 Mark the Md5PasswordHasher class as an implementation of the IPasswordHasher interface line 33 Change the type of the password hasher used by UserManager to IPasswordHasher line 3 Add a new constructor parameter of type IPasswordHasher interface line 5 which is the instance the UserManager class will use to hash its passwords This way we delegate the creation of dependencies to the user of the class and allows the user to provide any implementation it wants allowing it to control how the password is going to be hashed This is the very essence of inversion of control Minimize class coupling The user of the UserManager class has now control over how passwords are hashed Password hashing control has been inverted from the class to the user Here is an example on how we can specify the only dependency of the UserManager class IPasswordHasher md5PasswordHasher new Md5PasswordHasher UserManager userManager new UserManager md5PasswordHasher userManager ResetPassword luis aguilar 12345 So Why is this useful Well we can go crazy and create our own hasher implementation to be used by the UserManager class Plain text password hasher public class PlainTextPasswordHasher IPasswordHasher public string Hash string plainTextPassword Let s disable password hashing by returning the plain text password return plainTextPassword Usage IPasswordHasher plainTextPasswordHasher new PlainTextPasswordHasher UserManager userManager new UserManager plainTextPasswordHasher Resulting password will be 12345 userManager ResetPassword luis aguilar 12345 Conclusion So this concludes our article on Inversion of Control Hopefully with a little more practice you will be able to start applying this to your code Of course the biggest benefit of this technique is related to unit testing So What does it has to do with unit testing Well we re going to see this when we get into type mocking So stay tuned Further Reading The Strategy Pattern by OODesign Design Patterns Elements of Reusable Object Oriented Software book at Amazon Share this Email Facebook Twitter Like this Like Loading Related April 3 2013 by Luis Aguilar Categories NET Programming 6 Comments Post navigation Unit Testing 101 Basics Overview Of The Task

    Original URL path: http://blog.informatech.cr/2013/04/03/unit-testing-101-inversion-of-control/?shared=email&msg=fail (2015-08-19)
    Open archived version from archive

  • Unit Testing 101: Basics | Informatech CR Blog
    return true if validation is successful Running Tests Once you have your fixture ready to go is now time to run all tests on it and see results I will be using the NUnit GUI Runner which looks for all classes in the assembly marked with the TestFixture attribute and then calls each method on them marked with the Test attribute Is important to remember that all tests must be in a separate class library First reason is because it is a good practice you should not be mixing application code with test code and second because the NUnit test runner can only load DLL files So first thing to do is to build the project so we have a DLL containing all our tests Once we have a DLL file with our test fixture classes on it fire up the NUnit test runner NUnit exe and load the file on it At this point everything is quite intuitive You can hit the Run button and see how all tests pass or rebuild the project on Visual Studio and see how the test runner auto updates with new changes Cool huh Arrange Act and Assert Test methods are usually composed of three common phases Arrange act and assert Or triple A if you like Arrange At the very beginning of the method you need to setup the test scenario This includes expected test results for comparison with actual results instances of the components to be tested and type mocking Act After arrangement is done we now have to actually perform the actions that will produce the actual test results For instance call the Validate method on the UserAuthenticator class which performs the actual user validation Assert The assertion phase verifies that actual tests results match what we are expecting Is a good practice to provide comments delimiting each phase Test public void ShouldReturnTrueValidationIsSuccessful Arrange var expectedResult true var userAuthenticator new UserAuthenticator Act var actualResult userAuthenticator Validate luis aguilar 1234 Assert Assert That actualResult Is EqualTo expectedResult message Authentication failed though it should have succeeded As you might see these three phases are executed in order Is a good practice to initialize variables with expected results at Arrange phase to make the Assert phase more readable Also for the sake of readability I am using the Assert That syntax of NUnit so assertions are more verbose Tests Before Implementation Even though unit testing is good for all development methodologies I m an avid supporter of the Test Driven Development TDD methodology As the name implies TDD is all about writing all tests BEFORE you implement actual application code That way your code will meet acceptance criteria right from inception Basically application infrastructure design is driven by tests Now we think on user requirements rather than UML diagrams and classes For instance you should write all the previous sample tests before implementing the UserAuthenticator class That way that particular class will be born satisfying user requirements so we don t have to

    Original URL path: http://blog.informatech.cr/2013/03/29/unit-testing-101-basics/?shared=email&msg=fail (2015-08-19)
    Open archived version from archive

  • UI Design Using Model-View-Presenter (Part 1) | Informatech CR Blog
    public ClientsForm this clientsRepository new ClientRepository InitializeComponent BindComponent private void InitializeComponent Create and initialize window controls Omitted for brevity private void BindComponent this closeButton Click OnCloseButtonClick this clientsListBox SelectedIndexChanged OnClientsListBoxSelectedIndexChanged this clientsListBox DisplayMember Name this clientsListBox ValueMember Id this clientsListBox DataSource this clientsRepository FindAll private void OnClientsListBoxSelectedIndexChanged object sender EventArgs e var selectedClientId int this clientsListBox SelectedValue var selectedClient this clientsRepository GetById selectedClientId this clientNameTextBox Text selectedClient Name this clientEmailTextBox Text selectedClient Email this clientGenderTextBox Text selectedClient Gender this clientAgeTextBox Text selectedClient Age ToString private void OnCloseButtonClick object sender EventArgs e Application Exit First thing I would like to mention here is that this example satisfies all acceptance criteria you know what it is expected to do we established for the end product It shows the list of clients each time one is selected details of that client are displayed in the details group box and all that magic So what is so bad about this code It does what it should and best of all in roughly 49 lines of code Well as frustrating it might seem something effective is not always efficient The previous piece of code breaks pretty much all aspects of good design Martin Fowler might even shed a little tear just by looking at it Testing What Cannot Be Tested As I mentioned at the beginning of the article unit test code is as important as the actual business source code Always remember that lad Let s define a couple requirements this application needs to satisfy The clients application should as in has to Show all clients in the list box when it loads Show details of the first client in the list when it loads Show details of a client and show it when the user select an item in the clients list box Now let s write test method stubs for these using NUnit Framework namespace Codenough Demos WinFormsMVP TestFixture public class WhenClientsWindowLoads Test public void ItShouldLoadAllClients Test public void ItShouldShowFirstClientOnListDetails Test public void ItShouldShowClientDetailsOnListItemSelected When looking at these tests we can notice they are specific to the presentation portion of the application We are not testing data access the ClientRepository class or rendering related stuff By using the code example provided earlier our tests could fail or pass depending of The repository classes The data coming from the repository The stability of the actual Windows Forms libraries better known as the Please Don t Screw Up Microsoft prayer So we would have to adapt our tests for cases when the ClientsRepository class returns unexpected data or an environment related exception occurs when rendering the window on screen We simply can t perform proper testing of the source code as it is right now At this point code coverage has been compromised not even talk about separation of concerns The ClientForm class does friggin EVERYTHING But fear not Fortunately for us some nerds locked up in a server room under an average temperature of about 5 degrees celcius already encountered themselves in this

    Original URL path: http://blog.informatech.cr/2013/03/19/ui-design-using-model-view-presenter-part-1/?replytocom=379 (2015-08-19)
    Open archived version from archive

  • UI Design Using Model-View-Presenter (Part 1) | Informatech CR Blog
    this clientsRepository new ClientRepository InitializeComponent BindComponent private void InitializeComponent Create and initialize window controls Omitted for brevity private void BindComponent this closeButton Click OnCloseButtonClick this clientsListBox SelectedIndexChanged OnClientsListBoxSelectedIndexChanged this clientsListBox DisplayMember Name this clientsListBox ValueMember Id this clientsListBox DataSource this clientsRepository FindAll private void OnClientsListBoxSelectedIndexChanged object sender EventArgs e var selectedClientId int this clientsListBox SelectedValue var selectedClient this clientsRepository GetById selectedClientId this clientNameTextBox Text selectedClient Name this clientEmailTextBox Text selectedClient Email this clientGenderTextBox Text selectedClient Gender this clientAgeTextBox Text selectedClient Age ToString private void OnCloseButtonClick object sender EventArgs e Application Exit First thing I would like to mention here is that this example satisfies all acceptance criteria you know what it is expected to do we established for the end product It shows the list of clients each time one is selected details of that client are displayed in the details group box and all that magic So what is so bad about this code It does what it should and best of all in roughly 49 lines of code Well as frustrating it might seem something effective is not always efficient The previous piece of code breaks pretty much all aspects of good design Martin Fowler might even shed a little tear just by looking at it Testing What Cannot Be Tested As I mentioned at the beginning of the article unit test code is as important as the actual business source code Always remember that lad Let s define a couple requirements this application needs to satisfy The clients application should as in has to Show all clients in the list box when it loads Show details of the first client in the list when it loads Show details of a client and show it when the user select an item in the clients list box Now let s write test method stubs for these using NUnit Framework namespace Codenough Demos WinFormsMVP TestFixture public class WhenClientsWindowLoads Test public void ItShouldLoadAllClients Test public void ItShouldShowFirstClientOnListDetails Test public void ItShouldShowClientDetailsOnListItemSelected When looking at these tests we can notice they are specific to the presentation portion of the application We are not testing data access the ClientRepository class or rendering related stuff By using the code example provided earlier our tests could fail or pass depending of The repository classes The data coming from the repository The stability of the actual Windows Forms libraries better known as the Please Don t Screw Up Microsoft prayer So we would have to adapt our tests for cases when the ClientsRepository class returns unexpected data or an environment related exception occurs when rendering the window on screen We simply can t perform proper testing of the source code as it is right now At this point code coverage has been compromised not even talk about separation of concerns The ClientForm class does friggin EVERYTHING But fear not Fortunately for us some nerds locked up in a server room under an average temperature of about 5 degrees celcius already encountered themselves in this predicament and

    Original URL path: http://blog.informatech.cr/2013/03/19/ui-design-using-model-view-presenter-part-1/?replytocom=382 (2015-08-19)
    Open archived version from archive