class: center, middle # Day 1 ### Git, Gitlab, Intellij, Unit Testing --- ## Gitlab * Is an open source **git repository** manager -- * You can install it yourself and have your own "gitlab", [see this](https://about.gitlab.com/installation/) -- * Or you can use [gitlab.com](gitlab.com) in a similar way you would use github.com -- --- ## Gitlab compared to Github -- * Gitlab is open source and you can setup your own internal gitlab -- * Pull Requests are called Merge Requests -- * Free accounts can have private repos (Gitlab.com compared to Github.com) -- * There are a few other minor differences, but nothing that should cause you any confusion * For a detailed list of differences see [https://about.gitlab.com/comparison/](https://about.gitlab.com/comparison/) --- ## Gitlab user roles * You can add users to projects and groups with a certain role * Owner, Master - Can do pretty much anything * Developer - Can clone, pull, push, comment, approve merge requests * Reporter - Can clone and comment --- ## Gitlab Setup 1. Go to gitlab.com in your web browser 2. Create an account (create **new one** or create **using Github account**) 3. Create an SSH key by following [these instructions](https://gitlab.com/help/ssh/README) (DON'T enter a pass phrase when prompted. Hit enter.) 4. Send your gitlab username to the instructor so you can be added to certain groups 5. Browse around the gitlab.com: groups, projects, settings... 6. Clone a repo to make sure everything is setup correctly --- ## How Will We Use Git - Via terminal, without the aid of a GUI - Why you ask? -- - Because it helps the git process to really sink in -- - Also we will create **feature branches** for our work - These will help keep our code organized -- - When to create a new branch? - New assignment - Trying something out (experiment) --- ## Git command review -- * fork a repo - not an actual git command for this, but very useful -- * git clone https://repo-url -- * git status -- * git checkout branch-name -- * git add * or git add . `or` git add specific-filename.txt -- * git commit -m "a most accurate message" --- ## More Git Commands * git push -- * git pull -- * git fetch -- * git branch `and` git branch -a -- * gite remote -- * git remote show origin -- * git remote add upstream url-of-a-repo --- ## Git walkthrough - [https://education.launchcode.org/gis-devops/walkthroughs/gitLab/index.html#walkthrough-gitlab) --- ## Intellij Refresher -- * We will use Intellij Community Edition (It's free!) -- * We will also use JDK 8 -- * Create a new project * Check JDK version in Intellij * Mark folders as src, test, lib, excluded... * Run your code * Run your tests * How to save files (they save automatically unless you turn that off) --- ## Intellij Tips -- * Ctrl Enter - Generate menu -- * Command shift o - Search for file -- * Command e - recently opened files -- * Command j - shows you a shorcut menu -- * Command shift - and + - expands for collapses code folding -- * Command / - adds // comment in front of selected lines (removes if already present) -- * Alt + Enter - Intentions menu (offers to solve problems for you) -- --- ## Intellij Tips pt2 -- * Open multiple files by splitting vertically or horizontally -- * Middle click or CMD click to go to source of a class or method -- * Show/hide method parameter name hints -- * Local history for a file - log of changes Intellij keeps (right click a file) -- * Do you have any tips you want to share? --- ## Java Project Structure Conventions -- * lib - contains jar files * out/build - the compiled class files * src * main - java sources files * test - test java source files --- ## Refactoring -- * Changing code without changing its external behavior * When do you want to do this? -- * Better techniques come along -- * New requirements must be met -- * The presence of "code smells" * Duplication * Bad naming conventions --- ## Examples of Refactoring -- * Renaming classes or methods -- * Moving methods to a different class -- * Moving classes to a different package -- * Using a new sorting algorithm -- * Using a feature in the language, that the previous coder didn’t know about -- * Validation rules need to change based on new requirements --- ## After a Refactor * How do we know everything still work? -- * We can give it the ol eye ball test... Looks good to me. Ship it! -- * Manually test the application a few times... I don't see any bugs. Ship it! -- * Run the automated tests!... uh oh that thing I forgot about is broken :( --- <img class="graphic" src="../images/ship-it-revert.gif"> --- ## Automated Testing -- Automated tests are code files that utilize all the features of your code -- * Your classes are instantiated -- * Certain methods are executed (hopefully most of them) -- * All in specific order to insure they all do what they are supposed to --- ## Benefits of Automated Tests -- * They verify that the code functions as it should * All good here * Oops, I just broke something with that last change -- * The tests themselves are documentation on what the code should do * Because the tests demonstrate proper usages of the code * With all the required inputs and expected outputs -- * Unlike in code comments the tests can’t become stale * Tests will fail if the code behavior changes --- ## Unit Test A specific type of automated test. -- What is a “unit”? -- * The **smallest testable** unit of work * Most likely that is a function, but not always -- * A single, clearly stated, desired behavior * Breaking it down this way makes is easier to find bugs when issues arise --- ## Unit of Work Examples A single, clearly stated, desired behavior -- * Method returns false if passed an empty array -- * Method throws exception if passed a negative number -- * Class constructor properly creates object when passed required parameters --- ## Best Practices -- * Test should be deterministic -- * Given the same starting state, the test will always have the same result * A test that passes “most of the time” is not a good test. -- * Grouped together properly and focused * Don’t test totally unrelated things in the same test method or even the same test file -- * Tests should pass before committing code -- * Don’t test getters and setters --- ## Writing a Unit Test -- The AAA's method helps to guide us -- * Arrange * Variables that you will need -- * Act * Call method(s) -- * Assert * Check for specific results --- ## Unit Test Components -- * Test * A single test function -- * Fixture * A class file containing one or more test functions -- * Test Runner * A library that executes the tests and provides a report * For us this will be a library called JUnit --- ## JUnit A Java library that provides classes, methods, and assertions for organizaing and executing unit tests. -- - Specifcally JUnit 4 -- - Why not JUnit 5? For some reason the Java testing community has not widely adopted it *yet* --- ## JUnit Annotations -- * @Fixture -- * @Test -- * @Before -- * @After -- * @BeforeClass -- * @AfterClass --- ## Instructor Led Walkthrough - [https://education.launchcode.org/gis-devops/walkthroughs/unit-tests](https://education.launchcode.org/gis-devops/walkthroughs/unit-tests)