Etiqueta: teampost

Chapter 6 activity

en por maku18blogen activity, TC3045, team, tostorsDeja un comentario

What two properties must be satisfied for an input domain to be properly partitioned? 

– The partition must cover the entire domain (completeness)
– The blocks must not overlap (disjoint)

What is an Input Domain Model (IDM)? 

An input domain model (IDM) represents the input space of the system under the test in an abstract way. It helps the test engineer to define and create better tests by establishing the structure of the input domain and partitions of this domain.

What gives more tests, each choice coverage or pair-wise coverage?

Pair wise, as it does a permutation for a value from each block with one of each block of the other characteristics.

Chapter 4 activity

en por maku18blogen activity, TC3045, team, tostorsDeja un comentario

For this post we are going to show how we solved the exercises for chapter 4 using TDD. We need to add new operations like multiplying and division for the Calc.java file. The test file only has a test for the add operation as it is the only function we have in the class.

testcalc1

First of all, we need to write simple tests that describe what our new operations do. Of course, these tests should fail as we haven’t coded the functions yet.

testcalc2

Now we can start writing the functionality now, we are going to start with the subtraction as it is the first test we should pass to move to the next one. On this exercise the order we decide to write the new functions does not matter, but in more complex projects we should have a specific order to write the new functions because some tests might have multiple dependencies.

testcalc3

The next step is to write the test for the divide function. Here we have a problem, we don’t know how to implement this function because it can return a double or an integer. To follow the TDD correctly first we have to make the test pass, right now the test only ask for an integer so we will write just the code to make that correct.

testcalc4

At last, the multiply function. Here again we ask ourselves if this function should be capable of accepting float values, but it is not specified on our tests so by now we will handle only integers for the input and output.

testcalc5

 

Now lets imagine some guys from testing added new tests, now with more specific cases trying to find faults in our code. They included a test that divides two integers but the result is non integer, a test for a division by zero,  and a test with negative integers. After running the tests this happens:

testcalc6

As we can notice, only the division function is not passing the new tests. On one test it is expecting float numbers, on the other test, it is expecting us to catch an error when the divisor is zero. This means that we need a refactor to return doubles and to detect divisions by zero. This will change some of our previous tests, the first division test is working but it is expecting integers, the new test is expecting  doubles, there is an inconsistency in the tests and we should define this with the team first. The final decision is that a division should return doubles because it gives a more exact result. With that information we can go back to the tests, modify them accordingly and now start working on the refactor.

testcalc7

With this exercise we practiced TDD and refactoring. We learned how important it is to have good tests that defines the requirements for each function and that show how specific behavior should be handled. Also, it showed us how in TDD the tests are the guideline of our code and that it can show design errors or inconsistencies before we start writing the code, a huge advantage over other methodologies.

The code of the exercise is available here:

Calc.java

CalcTest.java

Week 4 progress

en por maku18blogen review, TC3045, team, tostorsDeja un comentario

During this week we have discussed a lot about the project and the tools we are going to use from now. As we are working with a different development and we will only be doing the tests, we should work with tools that the dev team is comfortable using. The project is a web application, something that most of us have done before, but in different ways and using different tools. After talking a little bit with the other part of the team, we agreed to use VueJS instead of React for the front end, mainly because is a framework that most of use are familiar with. The database is going to be done with PostgresSQL, that already has it’s own testing framework. For the API the team decided to go with Golang and Travis for integration testing. The architecture looks like this:

architecture

The set-up is already available at the dev team repositories here:

Client – https://github.com/gdlroutes/client

API – https://github.com/gdlroutes/api/tree/develop

 

 

Project description

en por maku18blogen review, TC3045, team, tostorsDeja un comentario

The project we are going to be working this semester is about smart cities. The objective is to build a platform that collect data around a specific city using tools like ArcGIS and ReactJS. The platform will also create tours of the city using the data and analysis and then guide the user trough the city using the GPS localization of the user’s phone. We need to be able to create, update and delete walk registers of the users and for that we may need a database to save all those registers, we are not sure if that is a requirement for the project but we will take it into consideration for the research that will be described in the next paragraph.

Mostly the languages that we are going to be working with are JavaScript and Java and some tools are the already mentioned ReactJS, ArcGIS and probably NodeJS. We are still not sure if we will need an SQL or no-SQL database but it would be good to know frameworks or tools for integration testing. With that information our team looked for some testing frameworks that will allow us to make testing easier for us in every aspect of the development:

Espresso:
Espresso is a powerful tool for testing purposes for android. Made by google it allows for testing of android applications by simulating app interaction in your test cases. It even allows to test interactions between your app and others. By using assertions and telling espresso where to click and what to input it allows app flow testing and general responses.

JUnit:
For unit testing, as android is mainly done with Java, JUnit should be the go to tool for being able to test the code and have easy test automation. It is easy to implement and helps to develop by TDD.

Mocha:
Mocha is a feature-rich JavaScript test framework running on Node.js and in the browser, making asynchronous testing simple and fun. Mocha tests run serially, allowing for flexible and accurate reporting, while mapping uncaught exceptions to the correct test cases.

Since we will be using ReactJS for our project as the frontEnd framework, we need to really take in consideration the different tools we could integrate and use for its proper end-to-end testing. The ideal scheme is for users to constantly be using our system, so the most we focus on developing a high quality software, the best product will give to our customers.
We did a research and found out that we could start with diferent tools depending on the most accurate aproach.

NightmareJS:
NightmareJS is a high-level automation library wich has:
Niffy which detect UI changes and bus across releases of your web app, Daydream which is a chrome extension to record your actions into a puppeter script & Electron which helps you generate a cross-platform desktop app using html, css, js.

Enzyme:
Enzyme is a tool that goes great with Mocha. It is a JS testing utility for React that makes it easier to assert, manipulate and traverse a React Components’ output. It is said to be easy to learn (both Mocha and Enzyme) even for new users in a short period of time.

Protactor:
In class we talked about the goals on testing and mentioned Verification and Validation. Well, there is this tool called Protactor, which is for acceptance testing which means that a system is being tested to evaluate the compliance with the business requirements (or the validation stage). The bad thing about it is that it was originally designed for Angular, although it is possible to configure it to work with React. It also helps you testing your app against a wide variety of software.

Mongo-Orchestation:
We are still not sure what kind of database we are going to use for the project, but if we had to guess, we are probably going to need a no-SQL database because the data we will manipulate may be big or unstructured.  MongoDB is a database program that is based on documents, it is said that it’s easy to use and to set up in almost any project. To do testing easily in a MongoDB database there is Mongo Orchestation. Mongo Orchestration (MO) is an HTTP server providing a RESTful interface to MongoDB process management running on the same machine. This will help us to automate test for simple requests using mocked server responses.

Semester plan

en por maku18blogen planning, TC3045, team, tostorsDeja un comentario

This semester is going to last 14 weeks, and for watch one we have activities to be done and requirements to fulfill to make our project. We are going to be doing the testing part of an already existing project of another class from one of my partners. The product is probably a web application o our planning must try to cover everything from building the environment and testing the final product. Of course, this plan is probably going to fail as we don’t know very much about the requirements or tools we are going to use. However, it’s always good to have some idea of what we should be doing in each week. The plan for each week is the next one:

Week 1: Research for development and testing tools.
Week 2: Decide for the tools we are going to use and learn to use them.
Week 3: Develop the base of the project and have functional automated tests.
Week 4 and 6: Back-end configurations and testing connectivity.
Week 7 and 9: Initial tests for general features and work on them.
Week 10 and 11: Continue on the development of features.
Week 12 and 14: Requirements verification and validate the final product.

During this week we want to do some research for the tools that are available for coding and testing with more efficiency. We are going to write a document that has all our research by Saturday, this will help us to take a decision for the next week and start learning how to use the tools we choose. Our goal for this class with this project is to learn to implement the best practices for testing, we are going to try to have automated unit testing and integration testing.