Category Archives: Week 13

Is Your Interface Two-Faced?

CS SERIES (11).pngWhen coding, users always have to be conscious about the way their code may be implemented or used in the future by different services leading to potential misuse. After reading Code Health: Make Interfaces Hard to Misuse by Marek Kiszkis, it made me think about how important communication between testing code is.

I found this content useful because Kiszkis featured some examples that can show how an interface could be misused easily. The examples included:

  • Requiring callers to call an initialization function
  • Requiring callers to perform custom cleanup
  • Allowing code paths that create objects without required parameters
  • Allowing parameters for which only some values are valid, especially if it is possible to use a more appropriate type

Sam CS (17)It is also good to remember that at the end of the day, code should be defensive but not too defensive to the point that complexity is increased and performance overall is reduced. Kiszkis says “it is not always practical to have a foolproof interface” because there will be situations where some requirements are things that cannot be expressed in an interface.

After seeing so much content based on being careful about what you code it is surprising how this article says it is not necessary to plan too hard. I kind of understand why Kiszkis would say this but personally, I kind of disagree with this. The reason why I disagree is because if someone does happen to end up with more time to work on something than expected and they know it will make something more efficient, then why not go for it?

Overall, I appreciated what was shared in this article in terms of encouraging users to try and see issues that can arise with their code when it comes to interfaces. The main takeaway for me is that if something is brought up, or triggered by undefined behavior, a user should try and make it impossible for this to happen. A way of doing so is by adding things where necessary, like certain slots in his example. It does not have to be too specific but detailed enough so that it covers different aspects, similar to how we try to prepare for everything when it comes to equivalence class testing.

Article: https://testing.googleblog.com/2018/07/code-health-make-interfaces-hard-to.html

 

From the blog CS@Worcester by samanthatran and used with permission of the author. All other rights reserved by the author.

New Instances in JUnit

Martin Fowler’s Blog is an amazing resource for someone breaking into the field of Software Development — his blog posts are extremely easy to read and are very educational. Even older content is still relevant and helpful to read through, like this article on the reasoning and design decision behind JUnit tests creating new instances for each test. As someone who has only a bit of experience writing my own Unit Tests, this was pretty eye-opening.

So why does JUnit create a new instance for each test, and what does that even mean? Each time you run a test, a new instance of each object used in the test is created. This means that in one test, if you create an object or assign a value, that change will not carry over into any other tests. The idea behind this is called isolation, and although it may seem counterproductive, it is extremely important. It ensures that no test should ever do something that would cause another test to fail.

So what exactly makes isolation so important? The point of Unit testing is to bend and stress the basic structure of the source code. If all tests were relying on a shared state which was dynamically changed between one another, each would leave behind data that would impact the other tests. You’d end up testing not just the source code, but you’d also be dancing around the different tests you had already written. If each test weren’t isolated, it would make the main objective — testing the product — significantly more complex.

JUnit in particular provides functionality to support this isolation and make the job of the tester easier — things like the setUp method. If you want each test method to create an Array with 5 elements, you would place that in the setUp method for it to be run prior to each test as opposed to having to rewrite that piece of code for each test you have. This helps keep each test isolated, whilst still providing every test with a shared base state from which to run.

If you’re like me, you had encountered this problem while tinkering around with JUnit and kind of accepted it without questioning the purpose behind it. It’s intuitive and makes sense that each test should be isolated from the others, but it is also important to ask “Why?” or “What would change if this were different?”. It gives insight into the JUnit framework, and helps make a more effective tester.

From the blog CS@Worcester – James Blash by jwblash and used with permission of the author. All other rights reserved by the author.

For agile testing, fail fast with test impact analysis

https://www.infoworld.com/article/3305326/application-testing/for-agile-testing-fail-fast-with-test-impact-analysis.html

Regression testing is testing a piece of software to make sure any changes or additions have not broken any existing functionality. In agile development it is important to release your product as quickly as possible and because of that it is important to fix any failures quickly and efficiently. Developers need feedback as soon as possible but regression testing can take up to days to complete, so they often settle with CI or scale down testing. As a result, productivity is worse and the close to the deadline sprint is more painful. One common approach to speeding up regression testing is to remove end to end testing which causes developers to miss a lot of issues that have a very large impact on the user experience. Risk-based testing is another way organizations speed up the process but many believe it can require too much overhead. However some amount of risk-based testing has to be done in order to guide prioritization on what needs to be worked on.
Test Impact Analysis is a technique that rapidly exposes issues in code since the last time it was modified and tested. It does this by correlating all regression tests to code and select only the tests associated with the latest round of changes. It then orders those tests based on their likelihood of detecting problems and prioritizes the execution of the ones most likely to expose problems. This helps you find a majority of the problems in an extremely short amount of time. This also results in much tighter feedback loops which means failing builds get resoled faster. Test <> code correlation makes it easier to determine where additional tests need to be taken as well as streamline the defect remediation process. Test impact analysis can be applied to any test including unit tests and automated functional tests. With test impact analysis a specialized set of cases is selected and executed. Static analysis finds which code has been modified since the previous test run, then dynamic analysis correlates the regression test suite with the identified code and regression tests that do not touch the modified code are eliminated for the test run. Additional analysis is then run to determine which tests are most likely to expose a defect in the new code and then sorted so that the test most likely to expose the most problems is executed first then merged correlated code coverage from all of the executed tests is visualized versus the new or modified code map, making it simple to spot coverage gaps.

From the blog CS-443 – Timothy Montague Blog by Timothy Montague and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Record What You Learn

This week I also read the pattern “Record What You Learn”, and this is a pattern that I am not anywhere near doing correctly. I think that this problem is useful, and though not as significantly as the others, still one worth implementing. This pattern is essentially asking you to take notes and record all of the things that you’ve learned throughout your journey. Taking notes does help in learning, but its real power comes when you actually go back and review these notes. The author alludes to the previously mentioned by suggesting that we keep our notes in a medium that we are more likely to access and interact with. Often times notes are taken in a subject specific notebook or application, the problem with this can be actually going back to this material to review it since it may lack that personal touch. This problem can be alleviated by storing your notes in a personal wiki, journal, or blog, the key being that this medium is personal and that it is something we interact with often.

The author emphasized the idea that your notes should be a “nursery, not a graveyard”, meaning that these notes should be a source of progress and growth and not stagnation. Even if you go through your notes daily, if you are only trying to memorize what is in your notes rather than trying to gain new insights and making new connections with them your time could be better spent doing something else. The other great benefit of having these notes is the fact that they act as some sort of wiki for you. The author mentions this and I have seen the truth in that myself. There have been times when there was a problem/bug that I could not figure out and the solution required multiple different things to be done, when I originally learned to solve the problem it may have taken me hours to gather all of the resources and information, but after storing all of those steps in my notes, I do it in minutes. Taking notes can often be too mundane and boring to actually want to do but this pattern has really showed me that it’s worth powering through it. By recording what you learn you have a detailed history of your grown, your own personal archive, and source of future ideas and innovations and because of this I will definitely try to apply this pattern as well throughout my career.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Practice, Practice, Practice

This week I read the pattern “Practice, Practice, Practice” and the focus of this pattern is pretty obvious. An expected theme that I came across when reading this pattern was the importance of practice itself, but the author went beyond that and specified the type of practice that is most valuable. The technique of practice that is optimal is said to be “deliberate practice” in which “ a mentor would assign you an exercise based on her understanding of your strengths and weaknesses…”. This method of practice is good because the exercises that you are practicing with match your skill level and most important of all, you are receiving feedback. Depending on your performance, this mentor would then decide whether or not increase the difficulty of the exercises. I can see the value in practicing like this, a big thing stopping me and many others from going back and practicing is how boring and mundane it is and this method ensures that you are amply challenged.

Another aspect of practice that the author mentions that you don’t often hear about is relaxation. The author says “if you aren’t relaxed you’re not going to learn from the practice”, in my experience this could not be anymore true. The practice that you are doing should be relaxing, it should be done without a deadline in an environment where you can break things without consequence.That brings me back to the level of challenge once again, this is because the practice should be done at a difficulty where you can learn but not too difficult that you get frustrated. Having learn how much being relaxed helps in the learning process I intend to use this going forward. The goal is to get to the point where you enjoy your practice sessions if you do not then you should likely change how you are practicing, and if that still fails then it could be because you don’t really enjoy the thing you are practicing.

The other major point that the author hit upon was feedback, this topic has been addressed in other patterns throughout the book and this is because of how important it really is. Yes it is true that practice makes you better, but practicing the wrong this will make you better at the wrong thing. Feedback is important because it makes sure that while you are practicing you are doing things right and developing good habits.

This pattern has reinforced to me the importance of practice, but more than that it’s showed me the importance of CORRECT practice. I plan on implementing this pattern not only throughout my software career, but on any skill that I want to develop in the future.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Dig Deeper

Dig deeper is a very important apprenticeship pattern to remember throughout your career and especially one to pay close attention to early on in your career.  It stresses that just writing a solution that you found online or just guessed until it worked is not good enough. It is important to know why the code solved the problem that you were having.  You should also look as to why was this the chosen solution, why code A over code B. This will help you stand out at work as someone who is a more effective problem solver. This will also help so you don’t submit a project that is only half complete; maybe the question that was answered on stack overflow did not include a test that was specific to your work.  If you do not dig deeper into your solution you may not realize this and turn in an unfinished project. When you only scratch the surface and just barely do enough to get by or even less than that work falls to others. There is a set amount of work that needs to be done for each project. Just because you do less doesn’t mean less work needs to be done, it just means that you are putting a bigger burden on the rest of your team that needs to complete their own work and pick up your slack as well.

When moving on from school I intend to make it a point to set aside time to review all the work that I complete as well as try to fully understand other parts of the program that I have a chance to see before submitting my work.  I think this will be beneficial for a few different reasons. First it will help set an impression with both my peers and superiors that I am a thorough worker who puts extra effort into my code. More importantly though it will allow me to expand my knowledge and provide the best possible solution for the problem that I am presented with.  It will help a well rounded tool kit that I may not only use immediately but could be applied in the future too. Doing this early on will create a solid foundation to build on for the foreseeable future.

From the blog CS@Worcester – Tim&#039;s Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

Expose Your Ignorance

This week I read the section called Expose Your Ignorance. This sections is something i can relate to very well. I am a senior in college and by that time many people would think that you would be able to program thing by yourself.  You should know about at least 2-3 languages by now and have the knowledge to work in the real world however just like the section “White Belt” there are always going to be people better than you and you don’t know everything yet. It is still a learning experience and for me in the class that we are taking now the section we are doing for the project. Which is encryption services is still something I don’t know much about at all. Just saying that you know nothing about something would be better then you hiding and saying nothing. That is what a team is about. To help and encourage each other to do what you can do and that way you can help them when they need help. During hackatons that i go to when meeting new people if we wanna work on a project we all have to introduce ourselves to each other. We also have to tell people what we can and can’t do because if we depend on someone to the most important part of the project and they don’t have the knowledge to do it in the end we would not have a project to present. Also just because you don’t have the knowledge to work on the project you should not just sit around and do nothing. Take this time to learn a new language, download the library’s needed to work on the project, watch videos, and work with a project partner to see if there is anything you can do. Just like the section says people are more inclined to make themselves look competent then just to tell others that you don’t know what you are doing because there are people looking up to you for advice or employers looking to you for the knowledge. That is why this section teaches you that you that lying about knowledge inst worth it and to accept your faults and work on them another day.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

Use the Source

Problem

Without exemplars of good practice to study and emulate, the Practice, Practice, Practice pattern only entrenches the bad habits you don’t know you have. If you never walk a mile in someone else’s moccasins, you may come to believe that all shoes are meant to have stones in them. So how do you find out if your work is any good, given that those around you may not have the ability to tell good code from bad?

Solution

The solution the text offers is to seek out other people’s code and read it. Start looking into applications and tools you use every day. It allows to you to learn how other professionals write code, and the thought process behind creating the infrastructure you’re using. When examining open source projects, it’s best to download the most recent version and preferably from the direct source so you can inspect the history of commits and track future updates. Learn the codebase and how the files are structured. Think about how you would have done things differently, and if maybe you should rethink the way you do something because someone might have a better solution.

This pattern has good tips on learning from the source. I liked the idea of starting with tools and applications you work with every day, I think starting with open source projects is a great way to learn how current professionals are writing code and what practices they are utilizing. You may find things you disagree with and things that make you re-think how to approach a problem. I think it’s also good advice to seek out others to read code you’ve written and have them offer feedback. It refreshing to know that so much content is available open source, and it can give people like me access to real working programs that I can learn and possible contribute to in the future. I like the idea of looking into sites like Git, Subversion, and Mercurial and learning how these projects work, and what design patterns and algorithms they are using. I believe reading and understanding open source projects will make me a better programmer, and will help me greatly in my professional career as I continue to add to my toolbox of best practices.

The post Use the Source appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Sustainable Motivations

From the blog CS@Worcester – BenLag&#039;s Blog by benlagblog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Find Mentors

This is probably the most important pattern I have checked out in the book by Dave Hoover and Adewale Oshineye. The entire pattern is about finding a mentor/master that helps you walk “The Long Road” with more ease. Allowing you to grow and cultivate your skills into tools that will be used for the rest of your life. The authors make sure to note that since our profession is still relatively young, there aren’t many recognized “masters” of the art. However, your masters don’t have to be physically available to you at all times. Maybe you read a book about someone’s life who really interested you and you begin to develop a passion for the things the author enjoyed, that author will be your master regardless of whether you talked to them or not. They may even be deceased!

The authors go on to emphasize that just because you are the apprentice and your master is the master, doesn’t mean that they are the one and all-knowing god of coding.  No one knows everything. Be free to opportunities and don’t only talk to your master, learn from other masters and expand your mind with knowledge. Lastly, this chapter reassures you that there is no real risk to looking for mentors. While it may be difficult, the payoff would be huge for you. The only risk is getting rejected, which really is not that big of a deal. Most top-notch developers had memorable mentors to help them along the way.

This pattern will certainly affect how I go about things in the future. I had never really thought about going up to someone and asking to be their apprentice or “assistant” but I could actually see it working. I could see someone at a new job being a mentor to me but I could also see myself going to volunteer on a separate project outside of work just to get extra practice and that sense of apprenticeship. I really enjoy the thought of having a mentor, so that may be one of my next steps.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.