Author Archives: Jeanne Boyarsky

chromebook and att wifi – part 2

Posted on by
Reply

Two years ago, I set up my mother with an AT&T 4G wifi hotspot. Overall, she is happy with it. The hardware is starting to get less than optimal. It doesn’t keep a charge as long. I think a wire needs replacing. It shut down randomly twice. Since it is two years old, I decided to buy a new one for her and keep the old one for me to play with.

The price came down. Without a contact, the ATT Velocity hotspot is now $60. (two years ago it was $150). And this time, I could buy it from BestBuy rather than AT&T. A far easier buying experience. No shipping so sent right to me.

Setting up an account

Since I bought the hotspot from BestBuy rather than AT&T, I had to set up my own account online. Hardly difficult. The steps:

  1. Go to http://att.com/activateprepaiddata
  2. Enter the SIM number – this is listed as the ICCID on the bottom of the box
  3. Enter IMEI number – this is on a sticker inside the phone (easy to see before putting in the battery). It’s also on the bottom of the box.
  4. The zip code of the user – I used my mother’s
  5. Enter user’s email. I used my mother’s
  6. Pick a plan. I chose the same plan I had before. $25/month for 2GB
  7. Sign up for autopay
  8. Choose a password
  9. Then I went to manage account to set up a name. I repeatedly got “We seem to be experiencing system issues. Please try again later.” on saving. It was true though. I waited 5 minutes and then it saved.

Trying out the hotspot

The battery/case comes separated so I put that together. The device tells you the charge, connection strength and whether you have any new messages. Unlike last time, I didn’t have any messages right away. I had the flashing green light and six messages once I signed up for automatic payment.

New since last time – the device appears to tell you how much bandwidth was used up. This is an illusion. Once I started using data, it directed me to the web for this.

It still shows the number of connected devices.

I connected to the wifi using the default password from a Chromebook and went to http://attwifimanager. I logged in with attadmin (the default) and changed:

  • Network name (it prompted me that I would be disconnected so I reconnected) – I made sure to use a different password
  • The wifi password (it prompted me that I would be disconnected so I reconnected – should have done this with the network name to save a reconnect)
  • Set max number of devices to 2
  • On advanced settings, changed admin login

There was an option to hide the password on the device. I chose this because my mother wanted a password that has other meaning.

Connecting from the Chromebook

Connecting to the new wifi name is easy. Note that the network name is case sensitive
  1. Click the connection from the wifi list
  2. Type password

This didn’t work on the first shot. I tried from my iPad and also no connectivity. So I rebooted the hotspot and it worked.

To remember the connection 

  1. Click the wifi icon and click “Connected to X”
  2. Click network name
  3. Click “Prefer this network”
  4. Ensure “Automatically connect to this network is checked”
  5. Click “close”

 

How fast is the connection?

I ran a speedtest both to see how fast the connection was and to use a chunk of bandwidth to see how reporting worked. The answer was:

  • ping 36 ms
  • download 13 Mbps
  • upload 9 Mbps

Problems

Every once in a while, I have to push the power button on the wifi device for the ChromeBook to connect. I haven’t seen a pattern on this, but it only happens on trying to connect.

Support

Most problems can be dealt with online at att.com/my prepaid, but they do have a phone number: 800-901-9878

upgrading mockito – forwards and backwards

Posted on by
Reply

I upgraded Mockito from 1.X to 2.X. (Because I wanted to try out the JUnit 5 MockitoExtension.

JUnit 4

I like @RunWith(MockitoJUnitRunner.class). The two main benefits:

  • Inject mocks as instance variables instead of static call to MockitoAnnotations.initMocks(this);
  • Tells you about unnecessary mock setup calls you have.

JUnit 5

Instead of the Mockito Runner, you use @ExtendWith(MockitoExtension.class). This was written by the JUnit 5 team. The two main benefits:

  • Inject mocks as instance variables
  • Inject mocks as method parameters

What’s missing

In JUnit 5, Mockito no longer tells you about extra setup code that you should delete. And neither version automatically calls verify() like JMock does. I miss that feature and wish Mockito had it. It is nice to be able to have the mock library tell you the actual code didn’t call an expected value without having to remember to code a call to verify the mock. (If Mockito does have it and I didn’t notice, please leave a comment!)

converting 2K+ tests to junit 5 in one day

Posted on by
Reply

I set myself a goal to see if I could convert all the CodeRanch JForum tests to JUnit 5 in one day. And I mean with Java 5 package names, not just running them in JUnit 4 mode. (I wanted to see what edge cases I encountered). Let’s see how that went.

Forking

Ant doesn’t currently support JUnit 5. So I decided to create a fork of the code base for playing with JUnit 5. Which is fine. I wanted to automate as much of the process as possible so it’ll be easy to redo when the time comes. It’s also good because then I don’t have to worry about whether everyone’s IDE supports JUnit 5 yet. IntelliJ does if you are on the latest version and Eclipse does if you fiddle with it. Probably better to wait until after the official release of JUnit 5 and Eclipse before using JUnit 5 in the trunk anyway.

Scope reduction

I decided to only update the unit tests. We also have some functional tests with an odd hacked together way of loading the database.  (I wrote a lot of it so not criticizing others.) I’m sure this can be improved in JUnit 5. Will wait until release for that as well.

JUnit 3.8

We have 15 classes that still reference JUnit 3.8. They used a mix of a superclass that did inherit from JUnit’s test case and some that used JUnit 4 style annotations too. I decided to go through these by hand in the trunk (and my branch) and get rid of the references to JUnit 3.8. This was a pain because each one was a special snowflake. One even said it was deprecated with replacement code listed. But it took under an hour; a few minutes each. So not terrible.

As I was going, I missed noticing that the class missed annotation. I was excited to see that SonarLint flags this!

Migrating most of the code

I ran a program to migrate most of the code to the new syntax. Here’s the project on github.

This left me with 83 compiler errors to look at. Of those…

Manual clean up

  • Parameterized tests. The manual gives good examples of the options. Conversion was easy; I used a method source. I did run into two problems.
    • SonarLint false positive – If you only have parameterized tests, SonarLint still flags the class. This was fixed in Sonar per SONARJAVA-2390. However, SonarLint hasn’t been released since so need to ignore the error in my mind.
    • Eclipse false positive – If you only have parameterized tests, Eclipse doesn’t recognize it as being a JUnit test. I didn’t search to see if this was reported since it is so easy to work around. To “solve” both these problems, I added a non-parameteirzed test to the class.
  • Timeout. I had one test that used the @Test(timeout) parameter. It was clear from the manual how to convert this. I like that specifying the time uses Java 8’s Duration class. This lets you specify the timeout in a readable way rather than in milliseconds.
  • Expected exception. I had 16 tests that used the @Test(expected) parameter. I thought about automating this but decided against it. This is a good opportunity to add an assertion about the message to most of them. Which we should have done originally. But it was *so* easy to just write the type and be done with it before. Also, it isn’t 16 distinct classes. A number of them have multiple validation type methods.
  • About 25 of our tests use JMock. @RunWith(JMock.class) doesn’t go with JUnit 5. Since JMock was abandoned (last release in 2012), I decided to switch to the “long way” and call context.assertIsSatisfied(); for now. About half of them extend the same superclass at least. I also made a note that we should migrate away from JMock.

Then I attempted to run all the converted tests

I ran into one problem

  • One of our tests was relying on the order in which the @Before methods were run in the superclass. This behavior was never guaranteed and changed from JUnit 4 to JUnit 5. I fixed the code to not rely on the order. (And or course, the place this happened was a superclass test so it resulted in a large number of failures until I figured out what was going on!)

Observations

I met my challenge. 2K+ tests migrated in one day. And I observed that one superclass caused the vast majority of the special cases!